mikebridge opened a new pull request, #42642:
URL: https://github.com/apache/superset/pull/42642

   ### SUMMARY
   
   Migration `df3d7e2eb9a4` (2024) intended to drop the legacy 3-column unique 
constraint `_customer_location_uc` `(database_id, schema, table_name)` from 
`tables`, but passed a **list** to `generic_find_uq_constraint_name`, whose 
body compares `columns == set(uq["column_names"])`. `list == set` is always 
`False` in Python, so the constraint was never found and never dropped — a 
silent no-op.
   
   Consequences on databases migrated through it:
   
   - The NULL-leaky 3-column constraint (no `catalog` leg) is still present, 
while schemas built from model metadata (`create_all`, e.g. CI) carry the 
model's intended 4-column constraint `(database_id, catalog, schema, 
table_name)` instead — so CI cannot reproduce production failure shapes.
   - A row keeps occupying `(database_id, schema, table_name)` **across 
catalogs**: creating the same table under a different catalog passes every 
catalog-aware app-level check and then hits an opaque `IntegrityError` only on 
migrated databases.
   
   Two-part fix:
   
   1. `generic_find_uq_constraint_name` now coerces its `columns` argument to a 
set (parameter widened to `Collection[str]`), removing the foot-gun for all 
callers. Existing set-passing callers are unaffected.
   2. A take-2 migration (`16755d4ca4ae`) re-attempts the drop with exact set 
matching. It is a harmless no-op where the constraint is already absent, and 
the model's 4-column constraint can never match a 3-column set comparison, so 
it is not at risk. Downgrade restores the legacy constraint best-effort (rows 
written after the drop may legitimately collide across catalogs), mirroring the 
tolerant try/except posture of the constraint's original creator.
   
   ### BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF
   
   N/A — schema-only change.
   
   ### TESTING INSTRUCTIONS
   
   1. `pytest tests/unit_tests/utils/test_core.py -k generic_find_uq` — 3 
tests: the list-argument regression pin (fails against the pre-fix helper), the 
set-argument happy path, and the exact-match guarantee (a 3-column lookup never 
matches the model's 4-column constraint).
   2. Migration verified on **SQLite and PostgreSQL**: fresh full-chain 
`superset db upgrade` (clean), then `superset db downgrade` (constraint 
recreated: `_customer_location_uc (database_id, schema, table_name)`), then 
`superset db upgrade` (constraint dropped), with `uq_tables_uuid` untouched 
throughout. On a database that still carries the legacy constraint, the upgrade 
drops it; on one that never had it, the lookup finds nothing and the migration 
no-ops.
   
   ### ADDITIONAL INFORMATION
   
   - [ ] Has associated issue:
   - [ ] Required feature flags:
   - [ ] Changes UI
   - [x] Includes DB Migration (follow approval process in 
[SIP-59](https://github.com/apache/superset/issues/13351))
     - [x] Migration is atomic, supports rollback & is backwards-compatible
     - [x] Confirm DB migration upgrade and downgrade tested
     - [x] Runtime estimates and downtime expectations provided: single `ALTER 
TABLE ... DROP CONSTRAINT` on `tables` (or a no-op lookup); sub-second on 
PostgreSQL/MySQL, table-rebuild via batch mode on SQLite. No data movement, no 
downtime expected.
   - [ ] Introduces new feature or API
   - [ ] Removes existing feature or API
   
   🤖 Generated with [Claude Code](https://claude.com/claude-code)


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to