Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft currency conversion configuration #790

Draft
wants to merge 2 commits into
base: master
Choose a base branch
from
Draft
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
45 changes: 43 additions & 2 deletions config/enrichments/currency_conversion_config.json
Original file line number Diff line number Diff line change
@@ -1,6 +1,5 @@
{
"schema": "iglu:com.snowplowanalytics.snowplow/currency_conversion_config/jsonschema/1-0-0",

"schema": "iglu:com.snowplowanalytics.snowplow/currency_conversion_config/jsonschema/2-0-0",
"data": {

"enabled": false,
Expand All @@ -11,6 +10,48 @@
"apiKey": "{{KEY}}",
"baseCurrency": "USD",
"rateAt": "EOD_PRIOR"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@istreeter What's your opinion on exposing the caching settings in parameters here similar to what we do for the API enrichment?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I paused for ages on this question! It makes me nervous to expose such a powerful setting in such a user-facing piece of config. Cache size is a balance between performance vs available memory, and the person configuring this enrichment might not know all of the context for tuning that.

On balance, though, it's better to make it configurable because we never know when we'll need to tune things at run time. So yeah we should put it in this config.

@miike what's your opinion on the ignoreOnError setting that is newly added to the sql enrichment config? If we added it here, it would basically mean.... if we fail to fetch a rate because of a network error, then it's OK to emit the event without the derived context.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the idea of ignoreOnError as there are going to be circumstances where a failed enrichment event (e.g., on checkout) is going to be annoying to not have because a currency conversion couldn't be performed.

I think this does raise the question (for both enrichments) about how you "recover" data that hasn't generated a failed event but might be NULL in the data warehouse though. I don't know that we can (or want to?) change our philosophy around the immutability of these events.

},
"mappings": [
{
"field": "contexts",
"schemaCriterion": "iglu:ecommerce.tracking/product_entity/jsonschema/1-*-*",
"derivedContext": "iglu:ecommerce.tracking/normalized_product_entity/jsonschema/1-0-0",
"currencyJsonPath": "$.currency",
"fields": [
{
"jsonPath": "$.price",
"outputField": "price"
},
{
"jsonPath": "$.list_price",
"outputField": "list_price"
}
]
},
{
"field": "contexts",
"schemaCriterion": "iglu:ecommerce.tracking/transaction_entity/jsonschema/1-*-*",
"derivedContext": "iglu:ecommerce.tracking/normalized_transaction_entity/jsonschema/1-0-0",
"currencyJsonPath": "$.currency",
"fields": [
{
"jsonPath": "$.revenue",
"outputField": "revenue"
},
{
"jsonPath": "$.tax",
"outputField": "tax"
},
{
"jsonPath": "$.shipping",
"outputField": "shipping"
},
{
"jsonPath": "$.discount_amount",
"outputField": "discount_amount"
}
]
}
]
}
}