-
Notifications
You must be signed in to change notification settings - Fork 3
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
Add contract and rate relationships tech doc #1806
Conversation
Add formatting.
Update contract-rate-refactor-relationships.md
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A couple suggestions for making this more complete. I think we should demo this doc when its merged!
@rswerve bat signal to you to also take a look with your great documentation eyes.
findDraftContract | ||
``` | ||
|
||
The lifecycle functions are used as follows |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this section! A couple suggestions:
- Discuss the rate functions discussed here too, not just the contract functions. Are the rates functions just the reverse of the contract functions? Are there any differences? This is fuzzy here because the rate functions aren't discussed.
- Would like to see
findContractWithHistory
andfindDraftContract
each have a one sentence description. It seems like they are supposed to be captured in the "one gotcha here" paragraph but its not very explicit how that relates to the functions themselves.
Just as we have maintained a list of package revisions up until now, this migration will entail the creation of a rates revision table. Every time a rate's info is updated, we will create a new entry in the rate revisions table with the new version of the data. This way a history of all past versions of the rate is maintained as a list of revisions. | ||
|
||
The trick is in tracking the history of the relationships between contract revisions and rate revisions. Since we only want to add a new entry to a revision table when the underlying form data changes, that means we need to track the relationships outside of those revision tables, and we need to be able to track a changing set of relationships between otherwise unchanged revisions over time. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you drop an image here or just embed/link an image from elsewhere in our docs?
|
||
## Migration plan summary | ||
|
||
Existing `HealthPlanPackage` submissions will be converted into Contract and Rates in the db. Since we will be working on the migration work behind a feature flag, we can write a migrator that runs repeatedly, taking the old protobuf encoded FormData and moving that data into our new `Contract[Revision]` and `Rate[Revision]` tables. This way we can test and refine our migration before we actually switch over to using the new data. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would like to see this section be even more explicit saying yes we are fully deleting health plan package tables after this change.
I feel like that detail could be missed right now.
something like - this is a full schema migration where we will first build a new parallel set of tables. After we migrate the submission data successfully in production, we end the use of the current HealthPlanPackage
tables in favor of Contract
and Rates
and their related tables going forward.
Summary
This doc covers how the contract and rate tables are laid out to allow for tracking relationships between them over time
Related issues
https://qmacbis.atlassian.net/browse/MR-3135