What order does migrate:rollback execute?

Why would someone want to manually add a row there?

But that isn't what I am asking... The question asks about the order of migrations being rolled back. Why someone wants to add a row there is not relevant to the question or the answer, besides being used as an example.

Rollback will execute the down method of your migrations.

If you run...

php artisan migrate:rollback --step=1

It will only rollback (aka run the down method on) your last migration. You can change the step number to rollback 1, 2, 3, whatever you want migrations.

That is useful. And yes, it rolls-back the down methods() but still, in what order?

ID DESC, or Alpha-numeric DESC?

I only started to consider this, because it migrates forward based on alpha-numeric, or date_created. Unsure of that too.

I would suppose this could just be tested in a matter of minutes? Create 2 migrations and migrate them. Add a new one in between them date wise. Migrate again. Now rollback 1. Which one is taken? The last or the middle one

Sadly I am not near a computer at the moment so I cannot test myself

@simonw In desc order. They rollBACK not forward. It starts with the last one migrated.

@fylzero Thank you. I think you somewhat missed what I was asking, but I assume you mean it starts with the highest ID, and goes back from there. Which answers my question.

Just to clarify, I understand its a rollBACK, but "back" is ambiguous if there is more than one way to roll back. It is equally likely that Laravel rolls-BACK the migrations in reverse order of the date in the migration instead of using the ID. Both methods would reverse the migrations in the correct order. And this is exactly why I gave the example of manually entering a migration in to the database, because at that point, the date becomes important.

Assuming it's ID. Thanks :)

I thought the explanation and code is clear

// We want to pull in the last batch of migrations that ran on the previous // migration operation. We'll then reverse those migrations and run each // of them "down" to reverse the last migration "operation" which ran.

/**
     * Rollback the last migration operation.
     *
     * @param  array|string $paths
     * @param  array  $options
     * @return array
     */
    public function rollback($paths = [], array $options = [])
    {
        // We want to pull in the last batch of migrations that ran on the previous
        // migration operation. We'll then reverse those migrations and run each
        // of them "down" to reverse the last migration "operation" which ran.
        $migrations = $this->getMigrationsForRollback($options);

        if (count($migrations) === 0) {
            $this->note('<info>Nothing to rollback.</info>');

            return [];
        }

        return $this->rollbackMigrations($migrations, $paths, $options);

    }


     /**
     * Get the migrations for a rollback operation.
     *
     * @param  array  $options
     * @return array
     */
    protected function getMigrationsForRollback(array $options)
    {
        if (($steps = $options['step'] ?? 0) > 0) {
            return $this->repository->getMigrations($steps);
        }

        return $this->repository->getLast();
    }

https://laravel.com/api/6.x/Illuminate/Database/Migrations/MigrationRepositoryInterface.html#method_getLast

array getLast()
Get the last migration batch.

Return Value
array

@simonw You reeeeeally shouldn't add a row to migrations or touch the migrations table ever. That would be an incorrect thing to do.

When you create migrations through artisan and migrate normally, the ids will align to the filenames. Adding a migration manually to that table is something that should LITERALLY NEVER be done for any reason.

If you need to update a table, make a new migration... work the timeline forward. Once migrations are in production, they should not be modified, ever.

The answer is, migrations rollback in the order they are created based on the date in the filename... which very well may be subsequently based on the id... why your asking does matter a bit... because the answer to whether this is using the id or date is irrelevant as they should always be aligned.

After a quick test with two migrations below

/**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        printf("table 1 created\n");
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        printf("table 1 deleted\n");
    }

/**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        printf("table 2 created\n");
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        printf("table 2 deleted\n");
    }

Here is the result of migrate command

php artisan migrate

Migrating: 2019_11_23_235642_test_migration_1
table 1 created
Migrated:  2019_11_23_235642_test_migration_1
Migrating: 2019_11_23_235704_test_migration_2
table 2 created
Migrated:  2019_11_23_235704_test_migration_2

Here is the result of rollback command

php artisan migrate:rollback

Rolling back: 2019_11_23_235704_test_migration_2
table 2 deleted
Rolled back:  2019_11_23_235704_test_migration_2
Rolling back: 2019_11_23_235642_test_migration_1
table 1 deleted
Rolled back:  2019_11_23_235642_test_migration_1

So it is clear that it will rollback the latest migration in the batch first. This is obviously the right way to rollback. Because the second migration might have something which is dependent on the first migration. So it is better to rollback the latest migration first.

For example the first migration may create customers table and the second migration will create orders table with a foreign key of customer_id which references the customers table. In this case, Rolling back the first migration will fail because the table has a column which is referenced on the orders table.