data-dwh-dbt-project/macros/user_migration_configuration.sql

44 lines
1.7 KiB
MySQL
Raw Normal View History

/*
Macro: get_new_dash_migration_phases_configuration
Provides a general configuration for the different phases of the
New Dash migration. Each phase is identifiable via a phase_name,
that is the "expected display" for users. The assumption is that
each user migration is identified via claim_type. Lastly, we
apply here a hardcode of when the deployment was carried out.
Important note: if a user migrates once a phase has started, we
will not be able to tell when that happened. However, it is likely
that other indicators will provide an estimate. For example:
The migration A happens on 1st July 2024.
User A is migrated on 1st July 2024 (as expected)
User B is migrated on 10th July 2024 (not expected)
It is likely that User B won't have Bookings from new dash
until it's migrated. So this migration date should be considered
as a hard, lower-limit of dates.
If a user satisfies more than one valid claims, in order to ensure
that the good date is considered we use the claim_enforcement_priority
value to force that a certain claim type will have precedence over
another. The lower the value, the more priority.
*/
{% macro get_new_dash_migration_phases_config() %}
{% set migration_phases = [
{
Merged PR 2849: Fix: KYG lite migration with proper date migration handling # Description This PR fixes the New Dash migration issue that happened on September 10th 2024. In this migration, users were directly assigned the claim of KygMvp that does not contain a date value. We were using a default hardcode of the first MVP migration, thus in DWH all users have been considered to be migrated late July instead of splitting the first 22 in late July and the ~200 others in September. The issue lies in the fact that users have configured a ProductBundle and can have Bookings with ProductBundle BEFORE the migration date, which greatly breaks the logic of a migration monitoring. Changes: * New migration phase added based on the claim MvpMigratedUser, that Ben created on Friday 13th * Adaptation of the code in int_core__user_migration to detect if the claim_value (a text field) has a date or not. If so, use that date as long as it's equal or greater than the deployment date, if not use the deployment date. If the claim does not contain a date, use the deployment date (this is the case for the first true 22 migrated users) I checked that volumes now look correct with this fix. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20773
2024-09-16 07:57:41 +00:00
"phase_name": "MVP",
"claim_type": "KYGMVP",
"default_deployment_date": "2024-07-30",
"claim_enforcement_priority": 1,
Merged PR 2849: Fix: KYG lite migration with proper date migration handling # Description This PR fixes the New Dash migration issue that happened on September 10th 2024. In this migration, users were directly assigned the claim of KygMvp that does not contain a date value. We were using a default hardcode of the first MVP migration, thus in DWH all users have been considered to be migrated late July instead of splitting the first 22 in late July and the ~200 others in September. The issue lies in the fact that users have configured a ProductBundle and can have Bookings with ProductBundle BEFORE the migration date, which greatly breaks the logic of a migration monitoring. Changes: * New migration phase added based on the claim MvpMigratedUser, that Ben created on Friday 13th * Adaptation of the code in int_core__user_migration to detect if the claim_value (a text field) has a date or not. If so, use that date as long as it's equal or greater than the deployment date, if not use the deployment date. If the claim does not contain a date, use the deployment date (this is the case for the first true 22 migrated users) I checked that volumes now look correct with this fix. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20773
2024-09-16 07:57:41 +00:00
},
{
"phase_name": "MVP",
"claim_type": "MVPMIGRATEDUSER",
"default_deployment_date": "2024-09-10",
"claim_enforcement_priority": 0,
Merged PR 2849: Fix: KYG lite migration with proper date migration handling # Description This PR fixes the New Dash migration issue that happened on September 10th 2024. In this migration, users were directly assigned the claim of KygMvp that does not contain a date value. We were using a default hardcode of the first MVP migration, thus in DWH all users have been considered to be migrated late July instead of splitting the first 22 in late July and the ~200 others in September. The issue lies in the fact that users have configured a ProductBundle and can have Bookings with ProductBundle BEFORE the migration date, which greatly breaks the logic of a migration monitoring. Changes: * New migration phase added based on the claim MvpMigratedUser, that Ben created on Friday 13th * Adaptation of the code in int_core__user_migration to detect if the claim_value (a text field) has a date or not. If so, use that date as long as it's equal or greater than the deployment date, if not use the deployment date. If the claim does not contain a date, use the deployment date (this is the case for the first true 22 migrated users) I checked that volumes now look correct with this fix. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20773
2024-09-16 07:57:41 +00:00
},
] %}
{{ return(migration_phases) }}
Merged PR 2849: Fix: KYG lite migration with proper date migration handling # Description This PR fixes the New Dash migration issue that happened on September 10th 2024. In this migration, users were directly assigned the claim of KygMvp that does not contain a date value. We were using a default hardcode of the first MVP migration, thus in DWH all users have been considered to be migrated late July instead of splitting the first 22 in late July and the ~200 others in September. The issue lies in the fact that users have configured a ProductBundle and can have Bookings with ProductBundle BEFORE the migration date, which greatly breaks the logic of a migration monitoring. Changes: * New migration phase added based on the claim MvpMigratedUser, that Ben created on Friday 13th * Adaptation of the code in int_core__user_migration to detect if the claim_value (a text field) has a date or not. If so, use that date as long as it's equal or greater than the deployment date, if not use the deployment date. If the claim does not contain a date, use the deployment date (this is the case for the first true 22 migrated users) I checked that volumes now look correct with this fix. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20773
2024-09-16 07:57:41 +00:00
{% endmacro %}