Smart seed migrations feature

[pave-epti]

Seeders are added in v1.3.0. It is a good start, but they are pretty basic and have shortcomings:

1. Hasura doesn't track which seeders are actually executed. There is db table schema_migrations, but we also need something like seed_migrations, which will hold information of executed seeders.
   In v1.3.0 release notes, there is a sentence which tells me there is intention for making smart seeders because they are called seed migrations, not only seeds.

   A new seeds command is introduced in CLI, this will allow managing seed migrations.

2. Hasura doesn't know how to auto apply seeders like it knows for migrations, so they are not sufficient for CI/CD.

So currently, if some necessary data needs to be seeded which will be the same for all environments, it is still better to use migrations and manually write up.sql and down.sql.

It would be also be nice to have a flag to force re-execution of the seed file, even if it is already executed and tracked in seed_migrations db table.

[Bessonov]

From my point of view, seeds are not the right way to create data. Instead, I would like to propose something like conditional migrations. I would like just use an env or config to run the "right" migrations.

[GavinRay97]

Hey folks :wave:

These are pretty big pieces of functionality. Will agree that in practice the seeds don't work out well without the ability to auto-apply from .cli-migrations image and not re-apply once run.

Will put this on the todo and see if someone from the CLI team can get to it soonish.

[DMezhenskyi]

I also find this feature very useful. It would be great to get it in upcoming versions

[scriptonist]

The sort of understanding I have for "seeding" is

• will be used mostly during development
• probably will be applied once and therefore tracking versions might not be required.

So, if we encounter a use case for something which we feel must be tracked like migrations, then maybe it should be treated as migration itself?