Skip to content

{185333845}: reject type-incompatible foreign-key constraints at sche… - #6100

Open
chands10 wants to merge 1 commit into
bloomberg:mainfrom
chands10:185333845-fk-constraint-type-check
Open

{185333845}: reject type-incompatible foreign-key constraints at sche…#6100
chands10 wants to merge 1 commit into
bloomberg:mainfrom
chands10:185333845-fk-constraint-type-check

Conversation

@chands10

Copy link
Copy Markdown
Contributor

…ma-change time

comdb2 matches foreign-key columns to the referenced key positionally (not by name), converting only the first min(local, parent) columns via stag_to_stag_buf_ckey. If a positionally-corresponding pair is type-incompatible -- e.g. a swapped key order that lines an int up against a cstring -- the conversion returns -1 at runtime: every write to the child table is rejected and existing rows fail verify with 'error loading rc = -1'. Nothing caught this at schema-change time: verify_constraints_exist only checked column counts, and even that is short-circuited when prefix_foreign_keys and superset_foreign_keys are both on (the legacy default).

Add a per-column type-class compatibility check to verify_constraints_exist so such a constraint is rejected up front on add/alter, guarded by a new runtime tunable fk_constraint_type_check (default ON). Startup is unaffected: existing tables load via populate_reverse_constraints, which is not touched, so a db that already has such a constraint still boots.

Add tests/fk_type_check.test and update tests/tunables.test per AGENTS.md.

…ma-change time

comdb2 matches foreign-key columns to the referenced key positionally (not by
name), converting only the first min(local, parent) columns via
stag_to_stag_buf_ckey. If a positionally-corresponding pair is type-incompatible
-- e.g. a swapped key order that lines an int up against a cstring -- the
conversion returns -1 at runtime: every write to the child table is rejected and
existing rows fail verify with 'error loading rc = -1'. Nothing caught this at
schema-change time: verify_constraints_exist only checked column counts, and
even that is short-circuited when prefix_foreign_keys and superset_foreign_keys
are both on (the legacy default).

Add a per-column type-class compatibility check to verify_constraints_exist so
such a constraint is rejected up front on add/alter, guarded by a new runtime
tunable fk_constraint_type_check (default ON). Startup is unaffected: existing
tables load via populate_reverse_constraints, which is not touched, so a db that
already has such a constraint still boots.

Add tests/fk_type_check.test and update tests/tunables.test per AGENTS.md.

Signed-off-by: Salil Chandra <schandra107@bloomberg.net>

@roborivers roborivers left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Cbuild submission: Error ⚠.
Regression testing: Success ✓.

The first 10 failing tests are:
noresetgen
consumer_non_atomic_default_consumer_generated **quarantined**
sc_downgrade [timeout] **quarantined**

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants