(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.

Reply via email to