Eloquent in migration

Question

Can I use eloquent in migration? The thing is, I need to add some values to the database, based on the relations I have set in the model. I know I could do it by query builder style with some SQL or somehow but it would be easier to just use eloquent. I am not sure if it won't appear as a mistake in the future. So, what to use in migration - eloquent or query builder?

Milesmilesian

Answer 1

Can I use eloquent in migration?

Yes, but it can be a bad idea.

Eloquent relies on your models to be in sync with your database. If there’s a difference, you may find that Eloquent struggles. Bear in mind that the migrations are specifically to deal with database queries, rather than any kind of object-driven data that you might get from them.

I would say as a rule, always stick to using DB in migrations. But there is nothing phyiscally stopping you from using Eloquent.

Foresaid

well yeah.. I know I can and also that I should not. But I am wondering if it is worth it to spend more time writing query builder or just use eloquent to save time – Milesmilesian

If you use Eloquent and you get away with it, then you’re good to go for now – but if you try running that migration in the future it will likely break eventually. Any kind of testing you’re doing will likely break. I would say stick to DB as annoying as it is. – Foresaid

What do you mean with if you try running that migration in the future it will likely break eventually? Can you explain what could cause this to break in the future? – Sacroiliac

@DuncanLuk Sure. Let’s say you change your Eloquent model because you change a field type or add a new field. Maybe you change a casting, add a mutation, add a relationship. Now that model can only work in the present, it can’t work in the past. Let’s say the relationship; soon as you use the model when that relationship doesn’t exist in the database, it’ll error. – Foresaid

But you can always be certain that that inside a migration the database structure is always the same, right? Inside the migration you know if that relation exists or not, and that does not change when you run it in the future – Sacroiliac

@DuncanLuk Not quite, because the model gets called during the migration, so there will be a state during the migration where the model does not refelect the database structure. Example, Migration 1 creates a table, Migration 2 amends the table. The Eloquent model has been updated to reflect Migration 2, but is used by Migration 1. When Migration 1 is called, the model will break, because Migration 2 has not yet happened. Perhaps a relationship is a bad example if it’s optional, but same applies with castings, mutations, etc. – Foresaid

Ah, I understand. You can be certain of the state of the database, but you can not be certain of the state of the code. Thanks for the explanation! – Sacroiliac

Answer 2

If you want you can use the Query builder or even Eloquent in your migrations. You could also run the database seeder via a migration:

/**
 * Run the migrations.
 *
 * @return void
 */
public function up()
{
    Schema::create('posts', function (Blueprint $table) {
        $table->increments('id');
        $table->string('name');
        $table->timestamps();
    });

    // Run seeders
    Artisan::call('db:seed');

    // Or run posts seeder
    Artisan::call('db:seed --class=PostsTableSeeder');

    // Or call Query Builder
    DB::table('posts')->insert([
       ['name' => 'Hiya'] 
    ]);
}

Eponymy