morph key column type should not be fixed to unsigned big integer

[eidng8]

• Laravel Version: 5.6.17
• PHP Version: 7.1
• Database Driver & Version: MySQL 5.6

Description:

Just migrated to Laravel 5.6, and found that morph methods in Schema\Blueprint have been changed to use unsigned big integer: morphs() & nullableMorphs by commit.

This change breaks a lot! And I don't think it could be easy or reasonable to change existing system for this. If this change has to be kept, it should provide a parameter to determine the type of column to be used.

To my case, the related columns of the morph targets are all auto increment unsigned integer primary key columns. I don't want to bring the INT vs BIGINT auto increment primary key argument here. The short answer is we can't change those primary keys to BIGINT.

My current work around is changing our migrations to alter the column type right after the Schema::create() call, and adds foreign key afterward.

        Schema::table(
            'a_morph_table',
            function (Blueprint $table) {
                DB::query('ALTER TABLE ....');
                $table->foreign('model_id', 'fk_to_other_primary_key_columns')
                    ->references('id')
                    ->on('target_table');
            }
        );

[SebastianS90]

@tillkruss why has this been closed?

I think morphs() should behave like increments(). If you need bigint morphs, then bigMorphs() would be a good alternative.

[Miguel-Serejo]

This was probably closed because it's a feature request, not a bug report. This repo is for bug reports.

Use laravel/ideas for feature requests.

[SebastianS90]

Changing the column types in a patch release (it was done in v5.6.5 -> v5.6.6) is a BC-breaking change, i.e. a regression. Users might have foreign keys for that columns...

And now my local system with a fresh database has other column types than the production environment, where the migrations have run with the old version.

[Miguel-Serejo]

This issue was about migrating to 5.6, where some BC breaks are expected. If the issue was from 5.6.5 to 5.6.6, I suggest you open a new issue where the title makes it clear that it's a bug report instead of sounding like a suggestion, and reference the pull request where this was changed.

Mind you, it would probably be too late to change this back on 5.6 since there have probable been a lot more 5.6 projects started after 5.6.6 than before, and changing it back would be a BC break for all of those.