Laravel has quite a convenient mechanism of dealing with database changes. It consists of Migration files for database structure and Seed files for sample data. But why separate them if sometimes it make sense to add it all to one file?
Let's say we are creating a new DB table called categories and we know from the beginning that there will be only three categories: "first", "second" and "third".
Option 1: separate migrations and seeds
In theory, we should create migration and seed files separately, like this:
1. Migration file:
php artisan make:migration create_categories_table
Then within the file itself:
public function up()
{
Schema::create('categories', function(Blueprint $table)
{
$table->increments('id');
$table->string('title');
$table->timestamps();
});
}
2. Then Model - app/Category.php:
class Category extends Model
{
protected $fillable = ['title'];
}
3. And then Seed file
php artisan make:seeder CategoryTableSeeder
And within Seed file:
public function run()
{
$categories = ['first', 'second', 'third'];
foreach ($categories as $category)
Category::create(['title' => $category]);
}
Option 2: seeding in migration file
In previous option, to launch all of that you have to launch separately artisan migrate and artisan db:seed, and probably add some code in seeding to check if those categories had not been inserted before. Personally, I like to "break the rules" and put seeding code directly into the migration file. Like this:
public function up()
{
Schema::create('categories', function(Blueprint $table)
{
$table->increments('id');
$table->string('title');
$table->timestamps();
});
$categories = ['first', 'second', 'third'];
foreach ($categories as $category)
Category::create(['title' => $category]);
}
And then - just artisan migrate and you have both table structure and seeding data.
Notice: of course, Category model has to be created before that.
The thing is that migration file and up() function can contain whatever code you want, not just Schema sentences. In theory, you can do something more - log something, add try-catch blocks etc.
I would advice something like that for simple few lines of data, where it's a small table. For more complex seeding with more fields/rows it does make sense to separate that action into seeds, taking care of checking if the table is empty etc.
What do you think about such method - more convenient, in my opinion, but maybe you know any drawbacks?
No comments or questions yet...