[BI-2995] Migrate parent ou ids in ou_level table to brapi ids - #19
[BI-2995] Migrate parent ou ids in ou_level table to brapi ids#19jloux-brapi wants to merge 3 commits into
Conversation
nickpalladino
left a comment
nickpalladino
left a comment
There was a problem hiding this comment.
I think this is another good one for @humsika to test
| FROM observation_unit ou | ||
| JOIN observation_unit_external_references ouex ON ou.id = ouex.observation_unit_entity_id | ||
| JOIN external_reference ex ON ouex.external_references_id = ex.id | ||
| JOIN levels_and_parent_ou_bi_id ON ex.external_reference_id = levels_and_parent_ou_bi_id.parent_bi_ou_id |
There was a problem hiding this comment.
Just a thought, could we restrict this match to the BI observation-unit external_reference_source and verify that each level_id maps to exactly one ou.id?
external_reference_id is not unique in the schema, so matching on it alone could produce multiple parent OUs for the same level. In that case, PostgreSQL UPDATE ... FROM may select an unintended parent ID.
| mol.ou_id::text | ||
| ) | ||
| FROM ou_ids_matched_on_levels mol | ||
| WHERE observation_unit_level.id = mol.level_id No newline at end of file |
There was a problem hiding this comment.
Could we add a migration assertion that fails when an expected parent relationship cannot be mapped, or when legacy parent IDs remain after this update? Rows missing a matching external reference are currently skipped silently, so Flyway could mark the migration successful while some records still contain the old BI-generated IDs.
I looked at the existing migration scripts, and we have a similar fail-fast assertion in V005.002__migrate_observation_levels.sql
3 participants
Description
Story: BI-2995
New migration added to change existing bi-generated exref observation unit ids being stored in the observation_unit_level table to brapi db ids to conform to cache removal swaps.
Dependencies
Testing
Checklist: