On 7/7/15 11:44 AM, Jon Rosebaugh wrote:
We have a test server where we automatically deploy various git branches of our codebase; these git branches sometimes have different Alembic heads and so the database needs to be upgraded or downgraded. For a long time we enforced a linear Alembic history and so this was relatively easy to automate. We want to allow branching and merging now, which means we may have problems. Consider the following tree: A -> B1 -> C A -> B2 -> C A -> B2 -> D (Where A is the a common parent, B1 and B2 are two branching revisions, C is a merge revisions, and D is a revisions whose parent is B2.) If I deploy a branch with C, but not D to the test server, and the database is currently at A, then we can automatically upgrade to revision C, which runs B1 upgrade, B2 upgrade, and C upgrade. Then I deploy a branch with D, but not B1 or C, to the test server. This means that for this branch, the database should reflect A -> B2 -> D. I want to downgrade C, downgrade B1, but not downgrade B2, then upgrade to D. I could approximate this situation by downgrading all the way to A, and upgrading back to B2, but if B2 is a migration that takes a while, that would be annoying. What is the best way to accomplish this? Essentially I want to take a set of revisions including the HEAD revision and remove them from the database. Is this what the "relnum+delta" specification syntax is for?
So I didn't actually know, but looking back at the source after trying this reveals that the delta syntax might be the only way that this does work, because by giving it a number, it gives you access to the "steps" involved. Usually to downgrade the "B1" and not the "B2" isn't possible because the syntax needs a target to go to, and if you give it "A" as the target then it un-does B2 as well, so yeah.
But then, in fact I don't think anything is possible at the moment because while I can get this to work by doing "alembic downgrade B1@-1", it does not seem to actually know what I want and it is basically just taking a random guess between B1 and B2 as the target to downgrade, so it works only 50% of the time.
Basically "downgrade" assumes a target revision in all cases and in this case, there isn't a target. it's just "half" the migration that we want.
if you were to splice a fake target in between A and B1, then you have somewhere to go. So I added an "a_to_b1_splice" that down revisions to A and B1 down revises to that, then I can "alembic downgrade <a_to_b1_splice_rev>".
That's all that will work now without changing the command interpreter to understand partial downgrades from within a series of branchpoints.
-- You received this message because you are subscribed to the Google Groups "sqlalchemy-alembic" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy-alembic+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
