Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
@@ -0,0 +1,29 @@
WITH
levels_and_parent_ou_bi_id AS (
-- Find observation_unit_level codes that contain a key by checking for a space in the level code.
-- Only other level codes that can exist are block/rep.
-- Then extract the uuid from the level code, since program key is also contained there.
SELECT
id AS level_id,
substring(level_code FROM '^([^ ]+)') AS parent_bi_ou_id
FROM observation_unit_level
WHERE level_code LIKE '% %'
),
ou_ids_matched_on_levels AS (
-- Now match the bi-generated exref ou ids to ex refs ids, and keep observation_unit_level ids for matching in next part
SELECT
ou.id AS ou_id,
levels_and_parent_ou_bi_id.level_id
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

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

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.

)
UPDATE observation_unit_level
SET level_code = regexp_replace(
observation_unit_level.level_code,
'^[^ ]+',
mol.ou_id::text
)
FROM ou_ids_matched_on_levels mol
WHERE observation_unit_level.id = mol.level_id

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

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