0

The obvious way to apply specific seeds rather than seeding everything is by using the --class flag:

php artisan db:seed --class[=CLASS]

Is there a way to track which seeders have been applied so far in Laravel (say, the same way you can track how migrations got applied by running php artisan migrate:status)?

Further, is there a way to apply a range of seeders (rather than specifying each class individually, which is very cumbersome).

What made me think about this is this part in a seeder in the book "Build APIs You Won't Hate":

28         foreach ($tables as $table) {
29             DB::table($table)->truncate();
30         }
31 
32         $this->call('MerchantTableSeeder');
33         $this->call('PlaceTableSeeder');
34         $this->call('UserTableSeeder');”

The idea is that every time you want to run the main seeder, you must start from a clean slate. But that's not practical for us in our staging environment at least which will always have a combination of seeding data and manual data entered by our QA/Operations staff.

halfer
  • 19,824
  • 17
  • 99
  • 186
abbood
  • 23,101
  • 16
  • 132
  • 246
  • Could you amend your seeders to use `updateOrCreate()` instead of `create()`and solve it that way? If all you need to do is make sure certain records are always present that would be one way to achieve it. – Matthew Daly Jan 05 '18 at 23:33
  • You could also make a table called `seeders` and treat it just like a database migration. You can extend the `Seeder` class and overwrite the `__invoke()` function to check if it has been previously seeded. – Ohgodwhy Jan 06 '18 at 01:03

2 Answers2

2

I believe this package was created to run seeders like migrations: https://github.com/slampenny/SmartSeeder. I think it will do what you are looking for.

The reason there is so little written about this, is that most of the time seeders are only used to initialize the database with data manually, and is not part of a more complex deployment process.

mike.bronner
  • 1,203
  • 1
  • 20
  • 39
0

This seems like an overcomplication of how seeds work, or an under-complication of your QA environment.

Maybe have different seeds for development and whatever you call staging/qa?

Phil Sturgeon
  • 30,637
  • 12
  • 78
  • 117
  • And how do we populate the staging seed? By automatically dumping live data? It's still the same problem.. we actually have different data for each env.. but it's the same code base.. and eventually we have to use the same seeding code in dev at staging – abbood Jan 06 '18 at 04:19
  • You can hardcode the IDs in your seed file, so you know which to delete. If your relationships are set up then all related data will cascade on delete and that'll clean things out nicely. – Phil Sturgeon Jan 06 '18 at 13:09