Repository navigation
Respect an explicit null modifier when changing a column - #254
JonasPardon wants to merge 2 commits into
Conversation
The ->change() shims used isset() to decide whether the migration set a modifier, which is false for null, so ->default(null) kept the old default instead of removing it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configuration
You can disable this status message by setting the Use the checkbox below for a quick retry:
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 |
|
@coderabbitai review |
|
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
On
wip/1.3, changing a column with->default(null)keeps the column's old default instead of removing it:The
->change()shims copy a modifier from the existing column when the migration didn't set it, and they check that withisset().isset()isfalsefornull, so an explicit->default(null)(or->comment(null), ...) is treated as "not set". This affects fresh installs and any new migration. It came up in wintercms/winter#1366, where a fresh database kept'niet betaald'as the default.array_key_exists()on the column's attributes instead, inMySqlBasedGrammar,PostgresGrammar,SqlServerGrammarandBlueprintState(SQLite). Laravel only adds the key when the modifier is called, so unset modifiers are still copied from the existing column.'niet betaald'toNULL.🤖 Generated with Claude Code