How to write a Laravel migration that depends on existing data?

Laravel doesn't support skipping migrations, does it? Because that would be cool!

@magmatic It wouldn’t.

Migrations are version control for your database schema. You don‘t skip migrations the same way you don’t “skip” commits when checking out a Git repository.

If a migration relies on records, then you need to insert those records in a previous migration.

@magmatic

Laravel doesn't support skipping migrations, does it? Because that would be cool!

You don't have to use migrations, you can connect to an existing database.

OK, OK, I hear you. I understand, I think. I'm trying to understand. But what about this situation?

Your website has a number of articles. In the articles table, there is a column called "private" and a column called "published". At some point you decide that instead of a number of flag columns, you need one column called "state", which could be things like "draft", "hidden", "private", "public". (The details are unimportant.)

Wouldn't it make sense to write a migration that adds this "state" column, then loops through all articles to calculate what it should be, then sets it accordingly, then drops the "private" and "published" columns? I would write a migration to do this. In my mind, a migration is the perfect solution.

My original question was, "How would you test this migration if there are no articles in the development database, because it hasn't been seeded yet?"

But now the discussion seems to be that I'm using migrations wrong. If so, can anyone think of a better, cleaner, simpler solution in this case than to use one migration that will automatically get run on deploy?

@magmatic I think your problem is, you’re thinking of how to do all of those steps in one, single migration. Break it down. You’d need to do it in multiple steps, just like you described.

You’d first create a migration that adds the state column with a sensible default value, and then a query after that sets the state value for any existing rows:

// 2024_08_23_000000_add_state_column_to_articles_table.php
Schema::table('articles', function (Blueprint $table) {
    $table->string('state')->default('draft');
});

Article::query()->eachById(function (Article $article) {
    $article->update([
        'state' => match (true) {
            // Logic to convert private and published columns to single state
        },
    ]);
});

With the state column added and its value set for each row, you can then drop the old columns in a second migration:

// 2024_08_23_000001_drop_private_and_published_columns_from_articles_table.php
Schema::table('users', function (Blueprint $table) {
    $table->dropColumn('private');
    $table->dropColumn('published');
});

You can now run your migrations in one go, and data will be migrated as well as your tables’ schemas.

@martinbean How is this different from one migration file?

@automica You said: "providing you have an env.testing you can test your migration works by running the following flag artisan migrate:fresh --seed --env=testing"

I don't think this is true, because there still won't be any data in the testing database to test on, since it's fresh, and the seed won't happen until after the migration.

@automica You said, "As others have said, if this is a one time migration, write what you want to do in a command, and then run that directly on your live environment."

If I change the database structure in a command instead of a migration, then running the migration files will no longer produce the correct database structure. I need a migration so that the database structure will remain correct.

@magmatic …or you could just migrate data in your migrations like I’ve mentioned multiple times in this thread now? 🤷‍♂️ Two of those times included my writing out two comprehensive code examples illustrating how to solve the “problem” presented by you.

If migrations were meant to be “paused” or stopped at arbitrary points, then they would support that.

@martinbean Of course I would migrate data in the migration. I assumed I would be doing that from the beginning.

The question was how to get data in there before the migration, in development, since seeding happens after migrating.

@magmatic Data doesn’t appear from thin air. I’ve shown you two different approaches now on how to deal with migrating existing data.

@martinbean I've gone back and re-read all your posts. I think I understand now your proposed solution to this problem.

However, after thinking about it, I think it's simpler to just rename the migration file to ".php.hidden", run a fresh migration, then rename it to ".php", then run migrate to really run it.

And since I'm all about removing complexity and embracing simplicity, this is how I'm going to handle this situation, since it's much simpler. It's a bit of a hack, but it's the best solution I've found so far.

But thanks for your suggestions.

🤦‍♂️