steder
commented
12 years ago The other part of this either detecting that a migration has already been run. After a rollback you'll want to move forward again and part of that is going to involve determining if a migration needs to be run again.
A couple thoughts that may make this easier:
- record hash of each migration that is run: should be able to determine if the script changed since it was originally run
- separate migrations that affect ddl from those that manipulate data: the idea is that if ddl has already been updated you don't need to run it. But a data migration may need to migrate any new data that was added during the rollback.
- mark migration scripts as idempotent / safe to rerun.
Being able to undo or reverse a migration could be a useful feature for testing and rollback.
I think the configuration file could be updated from:
migrations:
To something more like:
migrations:
The actual logic for running migrations in reverse should be pretty straightforward, we'll just need a toggle to explicitly enable rollbacks.
However, how do we handle something like:
migrations:
Can we rollback from 3 to 0? Or just from 3 to 2?
Must there be a reverse migration for every version?
Is it an error to try to rollback a migration that has no reverse or do you allow it?
Say we allow a rollback from 3 to 0. When rolling forward again to 3 or 4, do we rerun migration 2? I think we can reasonably be expected to remember that 2 was run and not run it again, but depending on the contents of 2 it may need to be rerun...
Ultimately this depends on having a workflow / migration policy for your specific project or schema so there's only so much we can do in the tool. We should be conservative in what we do and liberal in what we accept.