Skip to content
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

[8.x] Add dropConstrainedForeignId to Blueprint #34806

Merged
merged 1 commit into from
Oct 12, 2020
Merged

[8.x] Add dropConstrainedForeignId to Blueprint #34806

merged 1 commit into from
Oct 12, 2020

Conversation

amir9480
Copy link
Contributor

Hello.

This PR adds a new method dropConstrainedForeignId to the migrations which useful to drop columns made with foreignId.


A sample migration before this change:

class AddCategoryIdToPostsTable extends Migration
{
    public function up()
    {
        Schema::table('posts', function (Blueprint $table) {
            $table->foreignId('category_id')->constrained()->cascadeOnDelete()->cascadeOnUpdate();
        });
    }

    public function down()
    {
        Schema::table('posts', function (Blueprint $table) {
            $table->dropForeign(['category_id']);
            $table->dropColumn('category_id');
        });
    }
}

Same migration after this change:

class AddCategoryIdToPostsTable extends Migration
{
    public function up()
    {
        Schema::table('posts', function (Blueprint $table) {
            $table->foreignId('category_id')->constrained()->cascadeOnDelete()->cascadeOnUpdate();
        });
    }

    public function down()
    {
        Schema::table('posts', function (Blueprint $table) {
            $table->dropConstrainedForeignId('category_id');
        });
    }
}

@taylorotwell taylorotwell merged commit 86d08e4 into laravel:8.x Oct 12, 2020
@amir9480 amir9480 deleted the add_drop_constrained_foreign_id branch October 12, 2020 20:08
@coatesap
Copy link

Nice work, this should make the down migrations of FK constraints a bit easier in Laravel.

It's a shame that it's still not a symmetrical migration though, which would be more intuitive. We now have:

// up
$table->foreignId(...)->constrained()
// down
$table->dropConstrainedForeignId(...)

Whereas this would be a more symmetrical version:

// up
$table->constrainedForeignId(...)
// down
$table->dropConstrainedForeignId(...)

Or even (if we could automatically detect the constraint):

// up
$table->foreignId(...)
// down
$table->dropForeignId(...)

And we've got a similarly annoying lack of symmetry in:

// up
$table->foreign('column_name')
// down
$table->dropForeign(['column_name'])

Where the down suddenly requires an array.

I'm not sure if it's possible to smooth out these inconsistencies whilst dealing with backwards compatibility, but I'm happy to help if anyone has ideas.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants