add uniqueness constraints to cugs to take care of user_group_ids received from classrooms sometimes looking strange #47
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.
This hasn't happened yet, but I did notice that some classifications coming from classrooms will send
metadata.user_group_ids
with duplicates. (Eg. user_group_ids: [1234, 1234, 1234]).Adding uniqueness constraints to classification_user_groups to ensure that duplicates do not get created for classification.
Prework:
checked if there were any duplicates in staging and production:
SQL query:
select * from classification_user_groups ou where (select count(*) from classification_user_groups inr where inr.classification_id = ou.classification_id and inr.user_group_id = ou.user_group_id) > 1
there are 0 in both, but this could theoretically happen especially with finishing up the rest of ERAS backfill (Phase 4 Part 1, Creating Classification User Groups from backfilled classification_events)