Hi Andy, As you said, it is not a merge, more like a "checkout". To accomplish that with alembic, you would need to downgrade (see https://alembic.sqlalchemy.org/en/latest/tutorial.html#downgrading) from a4 back to root, and then upgrade up to b4.
On Mon, May 3, 2021 at 10:22 AM AndyS <andy.salni...@gmail.com> wrote: > (I posted this also on Stack Overflow, but realized that this may be a > better place for this sort of question) > > I'm trying to wrap my head around alembic features, and probably am using > alembic in a ways it was not designed for so I'm looking for some advice > from > experts. > > In my design I have two variants of database schema (e.g. "A" and "B"), the > variants are exclusive, a particular database instance has to chose to use > one > variant at initialization time. Both variants are changing during > development > and I use Alembic to manage schema upgrades for a single variant. For > management purpose my Alembic history for both branches starts with a > single > base which is also a branchpoint, something like: > > (branch: A) > +--> a1 --> a2 --> a3 --> a4 --> ... > / > root > \ > +--> b1 --> b2 --> b3 --> b4 --> ... > (branch: B) > > That works well, but now for some instances I'd like to switch from > variant A > to B, let's say from revision a3 or a4 to revision b4, something like: > > +--> a1 --> a2 --> a3 --> a4 --> ... > / | > root | > \ v > +--> b1 --> b2 --> b3 --> b4 --> ... > > This may look like a merge for revision a4 but it really is not, it is more > like "git checkout" but I also need to make sure that data from branch A is > migrated to branch B of course. > > I tried to introduce special migrations, e.g. branching at a4 and ending at > b4, but that confuses Alembic, apparently there cannot be two separate > migration scripts resulting in the same revision, i.e. "merge" is the only > way > to have more than one parent for a revision. But merge is not going to work > here too because b3 and a4 cannot coexist in the same database. > > I think it's obvious that standard history (from top graph) and a4-b4 > migration steps cannot exist in a common history, so I am thinking about > messing with Alembic by hiding its standard history and only exposing a4-b4 > step when I need to do this special migration, but I'm not sure if it's > going > to work well at scale (with many more special migrations). > > Did anyone have similar issues and was able to solve them reasonably, can > you > share your experience? > > -- > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sqlalchemy-alembic/37aa678f-a438-4288-a7fc-ae779187692fn%40googlegroups.com > <https://groups.google.com/d/msgid/sqlalchemy-alembic/37aa678f-a438-4288-a7fc-ae779187692fn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/sqlalchemy-alembic/CAOG-P07%3D%3DeJjJ_z07uqg7-_O2kuLAHgSPrtfH%3DRRgiSXLhP3sw%40mail.gmail.com.
