test: add regression for nullable hasMany onDelete behavior#18174
test: add regression for nullable hasMany onDelete behavior#18174PiyushInt wants to merge 1 commit into
Conversation
|
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)
📝 WalkthroughWalkthroughAdded a new test case to verify that nullable foreign key fields default to Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 OpenGrep (1.16.5)packages/core/test/unit/associations/has-many.test.ts┌──────────────┐ �[32m✔�[39m �[1mOpengrep OSS�[0m �[1m Loading rules from local config...�[0m 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 |
1 participant
This PR addresses #18172 for the v7 codebase.
In v7, the behavior for a nullable foreign key created via hasMany is already correct: when the FK column is nullable (i.e. allowNull is not explicitly set to false), the generated constraint defaults to ON DELETE SET NULL.
This change adds a regression test to lock in that behavior:
packages/core/test/unit/associations/has-many.test.ts
Verifies that when Foo.userId is defined without allowNull: false and User.hasMany(Foo, { foreignKey: 'userId' }) is used, Foo.getAttributes().userId has:
allowNull not forced to false
onDelete === 'SET NULL'
No runtime code changes were necessary; this is a test-only change to prevent regressions and to document the intended behavior for nullable 1:n associations.
Summary by CodeRabbit