Default column value not retained on column change

[simonworkhouse]

Laravel Version

11.16.0

PHP Version

8.2.18

Database Driver & Version

SQLite

Description

The defined default value is lost when modifying a column using SQLite.

Steps To Reproduce

After running the following migrations the default value of 456 is no longer present on the changed_col_with_default column.

Schema::create('products', function (Blueprint $table) {
    $table->double('changed_col_with_default')->default(456);
});

Schema::table('products', function (Blueprint $table) {
    $table->double('changed_col_with_default', 18, 2)->change();
});

Please see https://github.com/workhouse-advertising/laravel-framework/tree/bugfix/modifying-column-loses-default for additions to the testChangingColumnsWithDefaultWorks test.

[hafezdivandari]

Please check the docs and the upgrade guide

[jcrben]

@hafezdivandari thoughts on getting the original feature - where you only had to specify the things that need to change - back? This basically seems like a footgun - it's counterintuitive and easy to miss something. if nothing else some linting perhaps?

seems like https://github.com/laravel-doctrine/migrations might be the solution

[hafezdivandari]

thoughts on getting the original feature - where you only had to specify the things that need to change - back?

I don't think so. There are some good reasons for this behavior, mainly because that's how MySQL alter table modify column works.

seems like https://github.com/laravel-doctrine/migrations might be the solution

You can easily check column's attributes before changing via php artisan db:table or Schema::getColumns().

Laravel migrations has many more features than Doctrine, like support for default expression and generated columns. There were lot of issues with type changing via Doctrine DBAL, like enums, geometry / geography, year, time precisions, json, and etc.

[jcrben]

@hafezdivandari how a specific implementation works alone is not really a good reason for why handle an abstract concept like a migration should be limited.

Maybe there are reasons that this technical limitation makes it harder to support the ideal conceptual feature, which would make more sense - I'm curious about how MySQL alter table modify column makes it more difficult to retain existing column attributes.

These types of bug reports are just going to keep coming - people are going to keep shooting themselves in the foot - because this is a classic footgun.
cc: @taylorotwell

[hafezdivandari]

I'm curious about how MySQL alter table modify column makes it more difficult to retain existing column attributes

You may check PR #45487 and #48864 for further information.

These types of bug reports are just going to keep coming - people are going to keep shooting themselves in the foot

There is no bug? You should always check the upgrade guide for major version changes. This behavior has been documented since 10.x.

[jcrben]

@hafezdivandari I didn't say there was a bug, I said there was a bug report. Agreed that as long as it's documented, it's not technically a bug. A footgun is a counterintuitive feature which people use to accidentally shoot themselves in the foot.

I expect similar reports to continue in the future as people miss the docs and get confused.

[simonworkhouse]

@hafezdivandari Would support for a separate method (->changeWhileRetaining()) or perhaps a method argument (->change($retainSettings = false)) be considered? Not named like that exactly, but I believe you get the gist.

[hafezdivandari]

No plans for this at the moment from my side. Feel free to send a PR, but TBH I highly doubt it will get merged because it's impossible to implement that way without dropping some functionalities and introducing bugs.