[Sylvie-P]

HCK-18372 [Failing test] BigQuery reverse-engineering links the columns of a composite foreign key in a random order

## Content

Reverse-engineering a BigQuery table with a composite foreign key sometimes linked each child column to the wrong parent column (for example a_fk -> int_id and b_fk -> id instead of a_fk -> id and b_fk -> int_id). The result changed from one run to the next.

This is also why the Studio feature test test/feature/reverseEngineering/databases/bigquery.spec.js ("Reverse-Engineer from instance") fails from time to time on the composite_fk relationship.

Technical details

• The foreign key query joined CONSTRAINT_COLUMN_USAGE (parent columns) with KEY_COLUMN_USAGE (child columns) only on constraint_name. For a FK on 2 columns it returned the 4 combinations, in a random order, and reverseForeignKeys built the child and parent lists separately from that order.
• The query now pairs each FK column with the PK column of the referenced table using KEY_COLUMN_USAGE.position_in_unique_constraint, and returns ordinal_position. One row = one (child, parent) pair.
• reverseForeignKeys builds one relationship per constraint, with columns sorted by ordinal_position. The order of the relationships themselves is unchanged (first appearance), so the Studio expected model does not need an update.

Checked against the test dataset hackolade-bigquery-test.MyDataset:

• old query, 6 calls: the row order changes, and the code produced composite_fk [b_fk, a_fk] -> [id, int_id] in some runs (same mismatch as on CI);
• new code, 10 calls: always composite_fk [a_fk, b_fk] -> [id, int_id], simpleFK and fk$1 unchanged and in the same order as expectedRE.json.

Not checked: the full Studio feature test; the "Plugins, RE from instances" job on this PR should confirm it. FKs referencing a table in another dataset are still not found, same as before.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[taras-dubyk]

I suppose we may want to add sorting by constraint name if the flakiness continues, to ensure we always get the same order.
ORDER BY FK.constraint_name.