Laravel : Migrations & Seeding for production data

Laravel development is about freedom. So, if you need to seed your production database and think DatabaseSeeder is the best place to do so, why not?

Okay, seeder is mainly to be used with test data, but you'll see some folks using it as you are.

I see this important kind of seed as part of my migration, since this is something that cannot be out of my database tables and artisan migrate is ran everytime I deploy a new version of my application, so I just do

php artisan migrate:make seed_models_table

And create my seedind stuff in it:

public function up(){    $models = array(        array('name' => '...'),    );    DB::table('models')->insert($models);}

I've often found myself wondering what the right answer to this is. Personally, I'd steer clear of using seeding to populate required rows in the database as you'll have to put a load of conditional logic in to ensure that you don't attempt to populate something that's already there. (Deleting and recreating the data is very inadvisable as you could end up with key mismatches and if you're using cascading deletes you may accidentally wipe a load of your database my mistake! ;-)

I put the 'seeding' of rows into the migration script as the chances are, the data will need to be there as part of the rollout process.

It's worth noting that you should use the DB class instead of Eloquent models to populate this data as your class structure could change over time which will then prevent you from re-creating the database from scratch (without rewriting history and changing you migration files, which I'm sure is a bad thing.)

I'd tend to go with something like this:

public function up(){    DB::beginTransaction();    Schema::create(        'town',        function (Blueprint $table) {            $table->increments('id');            $table->string('name');            $table->timestamps();        }    );    DB::table('town')        ->insert(            array(                array('London'),                array('Paris'),                array('New York')            )        );    Schema::create(        'location',        function (Blueprint $table) {            $table->increments('id');            $table->integer('town_id')->unsigned()->index();            $table->float('lat');            $table->float('long');            $table->timestamps();            $table->foreign('town_id')->references('id')->on('town')->onDelete('cascade');        }    );    DB::commit();}

This then allows me to 'seed' the town table easily when I first create it, and wont interfere with any additions made to it at run time.

This is what I use in production.

Since I run migration on each deployment

artisan migrate

I create a seeder (just to keep seeding data out of migration for easy access later) and then run that seeder along with the migration

class YourTable extends Migration{    /**     * Run the migrations.     *     * @return void     */    public function up()    {            //migrate your table // Example        Schema::create('test_table', function(Blueprint $table)        {            $table->increments('id');            $table->timestamps();            $table->softDeletes();        });        //seed this table        $seeder = new YourTableSeeder();        $seeder->run();    }    /**    * Reverse the migrations.    *    * @return void    */    public function down()    {        Schema::drop('test_table');    }}

I do not add this seed call to seeds/DatabaseSeeder.php to avoid running it twice on a new installation.