Add ability for automatic database seeding

[Quadrubo]

I'd like the ability to automatically seed the database inside the Laravel Autorun Script.

Usecase

I have a Seeder that adds a default user to the database. I'd want to be able to run this anytime the application starts so there is a user to start with and my users can't get locked out. This seeder is written idempotently so it doesn't matter how often it executes. However this could be a problem for other seeders/applications where you only want your database to be seeded once.

Suggestion

Add two environment variables (suck at naming):

• AUTORUN_LARAVEL_SEEDING
• AUTORUN_LARAVEL_SEEDING_ALWAYS

If AUTORUN_LARAVEL_SEEDING is enabled the database will be seeded just once since this seems to be the default behaviour. This could be realized with the simple creation of a file but there has to be a better way.
If AUTORUN_LARAVEL_SEEDING_ALWAYS is enabled the database will be seeded on every run of the script.

I'd love some input on how to handle the "only run once" behaviour :)

[jaydrogers]

@danpastori: What are your thoughts on the proposal above? Does Laravel handle running seeding a database multiple times like migrations (where it's smart enough to not run things twice)?

[danpastori]

@jaydrogers I could see this being helpful through an environment variable that's defaulted to false.

Laravel will run things twice so you will have to account for that some way. Say if you seed initially, push an update, it will run again. I tend to manually seed through an artisan command so I have full control. If there's a way to run only once, I think that's practical, then handle the rest manually.

[jaydrogers]

How can I tell if the database has already been seeded?

Honestly, I almost feel the seeding might be best handled at the PHP level instead of the Docker container level.

Thoughts?

[danpastori]

You can't really tell if it's already been seeded. With migrations, the state is stored in the table. With seeds they aren't. I'd either have an option to auto run the seeds always, or not at all since there will be no way to just run it once:

https://laravel.com/docs/11.x/seeding#running-seeders

[Equinox07]

@jaydrogers
This would be very helpful considering seeding different data environment-wise relatively at docker level.
As to knowing if database had already been seeded can be handled at the PHP level using Eloquent's firstOrCreate, updateOrCreate respectively depending on the use case, all preventing multiple entry or seeding.

[jaydrogers]

The biggest challenge is if we do this at the CLI level, how does the user set firstOrCreate or updateOrCreate? Is it when they write the actual seeding command itself?

(sorry, you're talking to a sysadmin who knows <?php phpinfo(); ?> 🤣)

[DarkGhostHunter]

The problem of seeding is the environment and the location.

Seeding should never happen on production environment, so there should be a check for that like AUTORUN_LARAVEL_SEED_FORCE if the app environment is not {empty}, prod or production.

On SQLite, you cannot seed before migrating, where latest Laravel creates the SQLite database file. On older Laravel version, creating the file must be done manually.

In my opinion:

Laravel seeding should run on the container. This is because two reasons:

1. The developer may mount its own database.sqlite.
2. The database connection is only done when the container is live.

By this, then we should have access to configure the env variables like so:

• AUTORUN_LARAVEL_SEED=false, to seed the database after the migrations are done.
• AUTORUN_LARAVEL_SEED_FORCE=false, to seed the database if APP_ENV is {empty}, prod or production

To give some magic to the container, the AUTORUN_LARAVEL_SEED should also accept the seeder name, so it would call php artisan db:seed --seeder={seeder}, which can gracefully override the default seeder for a custom one, like StagingSeeder.