-
Notifications
You must be signed in to change notification settings - Fork 11.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tables with timestamps()
that were created in migration before v5.2, cannot be altered in migration in v5.3
#17313
Comments
That table |
This is the migration that originally created the table in v5.1 that was run in 2015:
This is the exact migration that I tried running in v5.3 yesterday when I discovered the issue:
|
@themsaid oh my bad, just realized you wanted the query. Here, I copied the create query from mysql workbench. Might just want to remove the foreign key's so that you can run it.
|
any updates on the best way to update a legacy table using |
@smenzer This is my work around. I put the following at the beginning of my up() function in the migration. DB::statement("ALTER TABLE `products`
CHANGE COLUMN `created_at` `created_at` TIMESTAMP NULL ,
CHANGE COLUMN `updated_at` `updated_at` TIMESTAMP NULL ;"); So this is how the whole "test" migration looks like: <?php
use Illuminate\Support\Facades\Schema;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Database\Migrations\Migration;
class AlterTable extends Migration
{
public function up()
{
DB::statement("ALTER TABLE `test`
CHANGE COLUMN `created_at` `created_at` TIMESTAMP NULL ,
CHANGE COLUMN `updated_at` `updated_at` TIMESTAMP NULL ;");
Schema::table('test', function (Blueprint $table) {
$table->string('name');
});
}
public function down()
{
Schema::table('test', function ($table) {
$table->dropColumn('name');
});
}
} |
I do believe this issue is more related to how MySQL works, there's nothing we can do about that, you'll need to run a script like this one: https://gist.github.com/wayneashleyberry/9fef63e6845f4375b8f19c8068a40f2b I think this will help prepare all your tables for strict mode. |
Thank you both. I know it's not Laravel-related, but I was just looking for the best way to do the migrations of my existing tables...both of the suggested solutions seem great so I'll implement one of them. Thanks! |
Description:
I have project that started out in 5.1, and has since been upgraded to 5.3.
Most of the tables were created in 5.1, so they have the old "not nullable" timestamps(). I also have some tables which were created in 5.3, and they have the new "nullable" timestamps(), and they work fine. (If you don't know what I'm referring to, see #11518)
Table that was migrated in 5.1:
Table that was migrated in 5.3:
The problem is, when I try to run a migration to ALTER, the OLD pre-5.2 tables (i.e. add or rename an unrelated column):
Even though the fields I'm changing have nothing to do with timestamps, I'm unable to alter the table.
Additionally, I cannot migrate the timestamps (without deleting all of the timestamp data) to the new "nullable" ones because:
Steps To Reproduce:
Step 1: Create a new project in laravel v5.1
Step 2: Run a migration to create a table with timestamps.
Step 3: Upgrade laravel to v5.3
Step 4: Run a migration to alter the table.
Step 5: You should get:
The text was updated successfully, but these errors were encountered: