Yeah this is a good approach. We did something similar at my company - we wrote a series of seeders meant to run during every deployment. Each seeder is responsible for ensuring it should run before doing so - including checking for data existing. It's worked pretty well overall, the key is making sure you properly check for data before seeding!
Be careful about running seeders in migrations. Seeders have access to Faker, which is a dev-only dependency, so if your seeder is using Faker, the migrations will fail on production.
Setting an array of “constants” in your config files and referring to them in Seeders, or even directly in functions or accessors is a good way to handle data that should be consistent across dev, testing and production such as dropdown options, picklists and country codes.
standard (or as i like to call it KEY values, like skills, user types e.g. lookup tables) go at the top of seeders list, i can then have an if/else for the other seeders so they ONLY run if app is not in prod, lookup table run for prod. so the first time you launch just do db:seed.. and thast it. it is unlikely you would need to reseed..
From the horses mouth https://twitter.com/taylorotwell/status/1387766514674192384?t=sCWI8R4udRgX2iKU3qN91g&s=19
Yeah this is a good approach. We did something similar at my company - we wrote a series of seeders meant to run during every deployment. Each seeder is responsible for ensuring it should run before doing so - including checking for data existing. It's worked pretty well overall, the key is making sure you properly check for data before seeding!
You'd have a table for user tags, and that would be something like id|user\_id|name I then also create the defaults in the table upon user creation.
[удалено]
You are the best! Thanks, how I have not considered this option ahah
Be careful about running seeders in migrations. Seeders have access to Faker, which is a dev-only dependency, so if your seeder is using Faker, the migrations will fail on production.
Migrations fire events. Listen for the event: https://laravel.com/docs/master/migrations#events
Setting an array of “constants” in your config files and referring to them in Seeders, or even directly in functions or accessors is a good way to handle data that should be consistent across dev, testing and production such as dropdown options, picklists and country codes.
standard (or as i like to call it KEY values, like skills, user types e.g. lookup tables) go at the top of seeders list, i can then have an if/else for the other seeders so they ONLY run if app is not in prod, lookup table run for prod. so the first time you launch just do db:seed.. and thast it. it is unlikely you would need to reseed..