Skip to content
Permalink
Browse files

[5.8] use bigIncrements by default

All new migrations will be using bigIncrements
laravel/framework#26472
  • Loading branch information...
ankurk91 committed Feb 24, 2019
1 parent 1d8add8 commit 426df7a0e4d489439002cf99c37246aeebdc5327
Showing with 1 addition and 1 deletion.
  1. +1 −1 database/migrations/2014_10_12_000000_create_users_table.php
@@ -14,7 +14,7 @@ class CreateUsersTable extends Migration
public function up()
{
Schema::create('users', function (Blueprint $table) {
$table->increments('id');
$table->bigIncrements('id');
$table->string('name');
$table->string('email')->unique();
$table->timestamp('email_verified_at')->nullable();

7 comments on commit 426df7a

@sebastienheyd

This comment has been minimized.

Copy link

sebastienheyd replied Mar 15, 2019

This needs to be documented here : https://laravel.com/docs/5.8/upgrade#upgrade-5.8.0

After updating from 5.7 this can result to an error if you use foreign_keys in your own migrations :

(errno: 150 "Foreign key constraint is incorrectly formed") (SQL: alter table `role_user` add constraint `role_user_user_id_foreign` foreign key (`user_id`) references `users` (`id`) on delete cascade on update cascade)
@laurencei

This comment has been minimized.

Copy link
Member

laurencei replied Mar 15, 2019

@sebastienheyd

This comment has been minimized.

Copy link

sebastienheyd replied Mar 15, 2019

I have the case, I updated from 5.7 to 5.8 by following the upgrade guide in a WIP project.

By doing this all my packages have updated but not the migrations in the project's database folder.

The error happens when running php artisan migrate:fresh, packages "up to date migrations" have bigInteger but not the migrations in the project.

@sebastienheyd

This comment has been minimized.

Copy link

sebastienheyd replied Mar 15, 2019

I fix it in the project folder, but I think that it's need to be documented.

@driesvints

This comment has been minimized.

Copy link
Member

driesvints replied Mar 15, 2019

@sebastienheyd like @laurencei said, this only affects new migrations. It doesn't needs to be in the upgrade guide. It's in the changelog if you want to reference any changes to the skeleton.

@sebastienheyd

This comment has been minimized.

Copy link

sebastienheyd replied Mar 15, 2019

Maybe I'm not explaining myself well.

I still had to modify the file "database/migrations/2014_10_10_12_00000000_create_users_table.php" by hand to put biginteger in it after going from 5.7 to 5.8. All this because a migration of one of the packages was no longer compatible... logic...

Indeed, if the project had already had its database in place, no problem. The new migrations would have been enough. But not with a fresh installation.

It would have been useful to see in the guide that the format of the id has changed and that it may have to be modified in case of problems.

I hope to be clear

@techouse

This comment has been minimized.

Copy link

techouse replied Mar 16, 2019

IMO there should be an .env option to keep the legacy $table->increments('id'); inside new migration files generated by Artisan, because this can get annoying really quickly with foreign keys.

Please sign in to comment.
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.