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

Split Primary/Vioscreen Surveys Into Separate IDs #270

Merged
merged 3 commits into from
Oct 23, 2020

Conversation

dhakim87
Copy link
Collaborator

Seems that our database has primary and vioscreen surveys sharing IDs in a number of legacy accounts. This is frustrating since we need the ability to say what type a particular survey ID is, and saying both isn't part of our model. This PR is a schema change to fork the IDs- primary surveys are assigned a new UUID and tables that reference the survey ID are updated or forked as necessary.

…a new uuidv4 id, vioscreen ids remain unchanged
…een and primary survey rather than just pointing everything at primary survey
Copy link
Member

@wasade wasade left a comment

Choose a reason for hiding this comment

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

this seems good... would it make sense to retain a record of old <-> new survey IDs just in case? One possibly stupid way to do it would be a create table legacy_mapping_patch_70 (old_id varchar, new_id varchar);?

@dhakim87
Copy link
Collaborator Author

I don't particularly need the old->new mapping afaik, if we're worried about data loss we should have snapshots from before the schema change. I did consider assigning the new IDs as some determined function of the old IDs, we could do that instead, but then we wouldn't have true uuidv4s anymore. The mapping is also (mostly) implicitly defined by looking at the ag_login_survey table -- anywhere a primary and vioscreen survey were taken for the same account and source either those two used to be the same ID or the surveys weren't taken until after the ID split.

@wasade
Copy link
Member

wasade commented Oct 21, 2020

True -- very good point regarding the rolling backups.

@wasade wasade merged commit 03410c1 into master Oct 23, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants