Auto seed

[DenuxPlays]

Feature Request

Would be great if we can configure a feature named "auto-seed" which seeds data at the very first start.
Kinda like how migrations are run. Save which file/function has already and run the rest.

Describe the solution you'd like

Create a new table and save the path of the file / name of the seeder and only run if it hasn't been found.

Describe alternatives you've considered

Implement my own system but that would be kinda pointless.

[DenuxPlays]

Also I would like to work on this if it gets approved.

[DenuxPlays]

I would start on the PR if the following pr was reviewed: #1063

I need to know if I can base on top of this pr or if this is something the loco team is not interested in.

All 3 prs (including this one) and:

• Fixtures use AppContext instead of DatabaseConnection #1063
• Added ability to seed via rust code #1061

would improve the functionality of fixtures.

[DenuxPlays]

I could also make one bigger pr if that is preferred.

[DenuxPlays]

Maybe @jondot and @kaplanelad can you help/state your opinion?
I am not sure if you are the correct person to ping but you helped/reviewed my last pr.

[kaplanelad]

Hey @DenuxPlays,

To create an auto-seed, you can use the before_run hook. If you want to add more conditions, such as checking the environment, you can easily control that with logic like the example below:

 async fn before_run(app_context: &AppContext) -> Result<()> {
        if app_context.environment == Environment::Development {
            Self::truncate(&app_context.db).await?;
            Self::seed(
                &app_context.db,
                PathBuf::from("src").join("fixtures").as_path(),
            )
            .await?;
        }
        Ok(())
    }

I don't know if you know this example, but what is better after seeing it?

Adding it as part of the hook is better than configuring it, as it allows you to add any conditions you need easily.

WDYT?

[DenuxPlays]

No.
This will reset the whole db and seed it which is no auto-seed.

I would implement a feature like with migrations.
Where you can say auto_seed: false and then add your custom logic inside the hook if needed.
Like the exact thing that we have with migrations.

[kaplanelad]

you don't need to call truncate function. this was only an example and you still getting the seed logic

[DenuxPlays]

Yeah I now
But this would involve the following:

• create table
• save which seeders have been executed
• only execute the rest

etc.

Sounds like something a few others can need.

[jondot]

Hi,
Just to follow up on the different PRs dealing with this topic.
Can you elaborate on what you are trying to do?

For example:

• When you have user auth systems with roles, usually after creating the roles table people like to insert all the different roles (this is a data migration)
• When you have, say a FOREX system, where you always need to keep an updated table of exchange rates, this is the kind of thing you do with a recurring loco task and the loco scheduler
• When you are running tests -- you call the relevant fixture test explicitly (this is done with current fixtures)
• When you are deploying to a new empty DB, you run migrations and then per environment you decide to explictly run the seed data

what is your specific use case that doesnt fall in this list?

[DenuxPlays]

@jondot I've opened a discussion which exactly describes your point.

See here: #1072