5.x: RFC - migrations reset/redo

[dereuromark]

What I am missing is some kind of quick redo, when you start a fresh app and you just modified the schema.

Laravel vs CakePHP Migrations

  | Reset (rollback ALL)       | migrate:reset          | ❌ Missing          | Rollback to version 0      |
  | Refresh (reset + migrate)  | migrate:refresh        | ❌ Missing          | Convenience combo          |
  | Fresh (drop all + migrate) | migrate:fresh          | ❌ Missing          | Nuclear option             |

I dont think we need all 3, the nuclear option could suffice. what do you think?
Maybe as "redo" or "rerun":

cake migrations redo

Asking for confirmation of course!

Similar thing could be for seeds:

cake seeds redo

would truncate and redo the data.

Both are useful when developing on a new app IMO

[dereuromark]

PS: I am already using the nuclear option in a way for test db reruns if sth is borked using Setup plugin:

bin/cake db wipe -c test

and then rerunning tests (which auto migrate)

Same is possible for default connection, of course.

But maybe its worth having the same in a more native way.

For seeds specifically the argument of a specific seed could be helpful when recreating data:

cake seeds redo MyArticles

[markstory]

Both are useful when developing on a new app IMO

I can see the utility in this. Can I ask that we require a --execute option to be set to actually delete the database? It would be awful to accidentally type cake migrations restart and drop a production database.

cake seeds redo MyArticles

Isn't this just running a seed with force?

[dereuromark]

Can I ask that we require a --execute option to be set to actually delete the database

Wouldnt this be actually as dangerous still? Since you could go up in history and click on the wrong thing as well (again).
My proposal would always require a manual Y typed, default N auto no-ops.
This would also be consistent with all other potentially destructive commands in the plugin then.

Isn't this just running a seed with force?

Well, not exactly:

• Seeds with --force: Re-runs seed inserts (may cause duplicates or constraint violations if table has data). this is mainly useful with updates and insertOrUpdate() to be added soon, or if "marked as run" to rerun it even if not idempotent.
• Seeds redo: Should truncate tables first, then re-seed (clean slate, removes noise or other things saved in the meantime), also requires a manual Y confirmation, of course.

In other words:

• --force tells it to ignore the "lock table entry" and rerun it despite being in the cake_migrations/cake_seeds table
• a real redo/reset would nuke the db table content before reapplying

[markstory]

Wouldnt this be actually as dangerous still? Since you could go up in history and click on the wrong thing as well (again).

Yeah it is possible. But you can't typo a help command into dropping a database. An interactive confirm would work well too.

[dereuromark]

I prefer the interactive one, if that is then consistent across the commands. Will have to double check of course.
I moved it to 5.next milestone as this is sth that can be added later without BC issues - on interface or alike.

[markstory]

I prefer the interactive one, if that is then consistent across the commands.

Forcing an interactive mode works for me too. You have to try hard to goof that up.