migrate:rollback + migrate:latest + seed

[endel]

Hi there! I hope all is well!

I'm wondering if we could have an alias like Laravel has for re-running migrations from "fresh" state, and then re-running the seeds? Laravel has a migrate:fresh --seed command for this.

Please let me know if this is a welcome change so I can send a PR. If there's a different nomenclature that fits best kysely-ctl let me know! I think Laravel's nomenclature is clear enough and we could use the same.

Cheers!

[endel]

I just noticed Laravel actually has fresh AND refresh 🤔
refresh does the rollback and fresh just drops all tables.
I could maybe send a PR implementing just refresh first.

[igalklebanov]

Hey 👋

fresh seems like a VERY dangerous operation, as migrations are not always guaranteed to start from the first table's creation, or some tables are owned by other libraries - e.g. better-auth.

Is refresh basically rollback --all && latest?

1. The naming is ambiguous. It's essentially a data wipe or rollback to seed (when --seed is there).
2. There's already a way to achieve this without adding confusion of yet another command.
3. This seems like something that doesn't scale well - gets slow very fast when you have lots of migration files to go over and recreates indexes. Could be achieved with a plugin+dummy driver that goes over all ups and collects all tables that were created but not dropped, truncates them, and maybe even resets sequences.
4. The north star is Knex compatibility - this mixes Laravel with Knex concepts.

[rebasecase]

If you use postgres, I automate this with a template database and two commands.

One to nuke the database, run migrations and seeds against a “golden” database template, and then dumps it using pg_dump.

The other creates the “real” database by restoring from the dump with pg_restore.

I make first command also runs the second command.

There is FROM TEMPLATE which you can use to replicate a database, but from what I understand this entirely locks the source database - which was unsuitable for me. I also found that a binary dump had better performance in some instances than piping the output of pg_dump’s sql into pg_restore, it likely is a better choice if you expect your database to grow significantly.

It’s easier if you stand up your postgres in docker, then you can nuke the whole thing and its volumes. This is what I do, and my scripts run against the container context.

Hope that helps/gives inspiration!