search

Electron100 / butane

An ORM for Rust with a focus on simplicity and on writing Rust, not SQL
Apache License 2.0
84 stars 12 forks source link

Detach latest migration #100

Closed jayvdb closed 11 months ago

jayvdb commented 1 year ago

Step one of https://github.com/Electron100/butane/issues/91 - detach rather than unmake.

jayvdb commented 11 months ago

I was a bit ambiguous initially planning to allow any migration to be detached. While detaching from the middle is do-able, it is less sensible to allow it, and it is not necessary for most common #91 scenarios. Doing multiple detaches of the top migration is sufficient, and adding support for re-attaching migrations is more important IMO.

Electron100 commented 11 months ago

Ack on the review request. Will take a look tomorrow.

jayvdb commented 11 months ago

Note two parts of https://github.com/Electron100/butane/issues/91#issuecomment-1567598015 that I havent implemented yet is

Undo it from the embed

and

When there is an existing detached migration, all commands would be disabled except for the "rejoin", with an error message informing the user how to delete the detached migration if they want to abandon it.

The first of those is mandatory.

IMO the second doesnt depend on "rejoin" being built first - all commands can be blocked until the detached migration has been removed - atm that means it is the users responsibility to do something with it or delete it. I'm happy to do that in the scope of this PR if you agree that is good enough for now.

If any command is necessary whilst detached, IMO it is "detachmigration" so that the user can remove multiple migrations from the top, in order to reach a common branch point between two branches of development.

jayvdb commented 11 months ago

I've added the ability to detect if there are detached migrations, but after looking through the existing list of commands I am reconsidering whether this is needed at all. While it might be usually a bad idea to run some of the commands when there is a detached migration, it cant cause new undesirable states which we must avoid, and maybe we should just let the user do the commands and let them deal with the repercussions.

What might be useful is to always print the list of detached migrations, so they are not accidentally forgotten.

Electron100 commented 11 months ago

I agree with your reconsideration -- it doesn't seem necessary to me to actually block operations for detached migrations.