Add contract and rate relationships tech doc #1806
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
haworku
requested review from
mojotalantikite,
rswerve,
haworku and
JasonLin0991
Add formatting.
Update contract-rate-refactor-relationships.md
haworku
approved these changes
Jul 17, 2023
| findDraftContract | ||
| ``` | ||
|
|
||
| The lifecycle functions are used as follows |
There was a problem hiding this comment.
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
findContractWithHistoryandfindDraftContracteach 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.
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.
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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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