artisan migrate fails on mysql due to BigintUserKeys migration

[peetersdiet]

trafficstars

Issue

When performing artisan migrate, migration fails due to the BigintUserKeys migration introduced with PR #109 .

The migration wants to change the user_id field in the role_user table to bigint. As stated in the Exception below, the user_id column of the role_user table cannot be changed because a foreign key exists.

$ ./artisan migrate
Migration table created successfully.

  [Illuminate\Database\QueryException]
  SQLSTATE[HY000]: General error: 1832 Cannot change column 'user_id': used in a foreign key constraint 'role_user_user_id_foreign' (SQL: ALTER TABLE role_user CHANGE user_id user_id BIGINT UNSIGNED NOT NULL)

  [PDOException]
  SQLSTATE[HY000]: General error: 1832 Cannot change column 'user_id': used in a foreign key constraint 'role_user_user_id_foreign'

Possible solution

Some remarks:

1. Dropping the key and recreating it after the column-change also fails with an exception. This is because the datatype of the id-field in the user-table (int) does not match the datatype of the user_id field in the role_user table (bigint).
2. Regarding the difference in datatype between the two tables, I do not think kodeine/laravel-acl should be changing Laravel's user-table, as this would potentially lead to clashes with other libraries using Laravel's user table.
3. Finally, I doubt the consistency of PR #109 . Why change the definition of a column on only 1 side of a foreign key relationship? Even in datastores that do not strictly enforce datatypes across foreign key relations, this will pose an issue when reaching the limit of the field with the smallest address-space. (not?)

I see two approaches to mitigate the problem:

1. Keep the user_id field in the role_user table as integer. This boils down to removing the conflicting migration completely.
2. Selectively apply the change to bigint: only for datastores that do not have an issue with foreign key relationships on asymmetric fields. Note that this solution leads to an inconsistent implementation of kodeine/laravel-acl across datastores.

My preference would be solution 1.

@kodeine: I do not know the rationale behind PR #109, but would you be open to removing the BigintUserKeys migration? If so, I will open a PR.

[fulopattila122]

This might help: https://github.com/artkonekt/laravel-migration-compatibility