Perhaps the most common (and reliable) solution is to use alembic merge heads . In the same way, when you have two branches in Git, you can merge them together with the merge commit, in Alembic, when you have two branches, you can return them together with the merge revision.
For example, suppose we have revision 1a6b1a4a0574, which adds table A, and revision 2e49118db057, which adds table B. We can see these revisions (both marked as (head) ) in alembic history :
$ alembic history <base> -> 2e49118db057 (head), Add table B <base> -> 1a6b1a4a0574 (head), Add table A
Then we can combine them by running alembic merge heads :
$ alembic merge heads Generating /Users/markamery/alembictest/alembic/versions/409782f4c459_.py ... done $ alembic history 2e49118db057, 1a6b1a4a0574 -> 409782f4c459 (head) (mergepoint), empty message <base> -> 2e49118db057, Add table B <base> -> 1a6b1a4a0574, Add table A
If one of your revisions may already have been started somewhere (including on the developer's machine of one of your colleagues), then you probably want to use alembic merge instead of messing with down_revision one of the revisions, as others suggest answers here, The danger of tinkering with the downgrade is that it can cause the revision to not be applied. For example, suppose your colleague Bob has already removed a branch with revision 2e49118db057 and launched alembic upgrade head , creating table B. Then you decided to change down_revision 2e49118db057 so that it points to 1a6b1a4a0574, which Bob has never seen or run before. Bob removes your changes, launches the alembic upgrade head , and ... nothing happens, because with regard to Alembic he is already in the head and he does not need to run 1a6b1a4a0574. And so Bob never gets table A and probably never finds out why his database is in a bad state.
Don’t break Bob’s database - instead do a merge revision.
Mark amery
source share