Enforce referential integrity at the database level

[maximerassi]

The default laravel 8 user id $table->id(); type does not match $table->unsignedBigInteger('user_id'); and this migration fails on fresh laravel 8 installs.

reference: https://laravel.com/docs/7.x/migrations#foreign-key-constraints

[maximerassi]

This feature was introduced in Laravel 7+.

Then an alternative solution would simply be to force change the user table id type in this migration. However this would require doctrine/dbal dependency.

Thoughts?

    public function up()
    {
        Schema::table('users', function (Blueprint $table) {
          $table->bigInteger('id')->unsigned()->change(); <--------- addition

          if (! Schema::hasColumn('users', 'avatar')) {
                $table->string('avatar')->nullable();
            }
        });

        Schema::create('social_providers', function (Blueprint $table) {
            $table->bigIncrements('id')->unsigned();
            $table->unsignedBigInteger('user_id');
            $table->string('provider')->index();
            $table->string('provider_id')->index();
            $table->timestamps();
            $table->foreign('user_id')->references('id')->on('users')->onDelete('cascade');
        });
    }

Here is the default laravel user migration. https://github.com/laravel/laravel/blob/8.x/database/migrations/2014_10_12_000000_create_users_table.php#L17

[joselfonseca]

This is failing for Laravel 6. We may need to find another way. We support Laravel 6, 7 and 8.

[maximerassi]

The other solution is to explicitly re-cast the users table id column within this migration. This would fix fresh installs on top of Laravel 8 but could break others who have a project in advanced stages referencing the users table.

        Schema::table('users', function (Blueprint $table) {
          $table->bigInteger('id')->unsigned()->change(); <--- add

          if (! Schema::hasColumn('users', 'avatar')) {
              $table->string('avatar')->nullable();
          }
        });

We can probably close this since there is already a reasonable workaround that's already documented https://lighthouse-php-auth.com/docs/customization/#customize-schema