Downgrading by specifying revisions to remove?

[Jon Rosebaugh]

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?

[Mike Bayer]

Post by Jon Rosebaugh
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
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.