meta(core): add regression test for foreign key duplication on schema-qualified alter#18228
meta(core): add regression test for foreign key duplication on schema-qualified alter#18228emmayusufu wants to merge 1 commit into
Conversation
…equelize#12961) sequelize#12961 is fixed on main (the alter-sync path now reads .tableName off the reference object instead of comparing the whole object), but there was no test guarding it. The existing foreign-key alter test uses the default schema and asserts nothing, so it wouldn't catch a regression here. Add a test that defines two related models in a non-default schema, syncs twice with alter: true, and asserts the foreign key count stays at 1. Reverting the fix makes this fail with a count of 2.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThis PR adds a single regression test for issue ChangesSchema FK Constraint Duplication Test
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Closes #12961.
That issue (duplicated foreign keys on every
sync({ alter: true })when the model is in a non-default schema) is already fixed onmain— the alter path now reads.tableNameoff the reference object instead of comparing the whole object, and matches on schema. But there was no test guarding it.The existing "should properly alter tables when there are foreign keys" test uses the default schema and doesn't assert anything, so it wouldn't catch a regression here.
This adds a test that puts two related models in a non-default schema, syncs twice with
alter: true, and asserts the foreign key count stays at 1. I confirmed it has teeth: reverting the.tableNameextraction makes it fail with a count of 2. Runs on any dialect that supports schemas; verified against Postgres locally.Summary by CodeRabbit
Model.sync()with schema customization properly handles foreign key constraints without duplication.