Thanks for suggestion! I was afraid someone was going to propose just that 😀 In my case root is completely empty schema (root is only there to give a label to whole thing) which means that I need to start from scratch and loose all data. In general downgrading (even going a4 to a1) in my situation means potentially losing data which I have to avoid, so I can't use that "simple" approach.
On Monday, May 3, 2021 at 11:16:23 AM UTC-7 sachi...@gmail.com wrote: > 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.s...@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-alem...@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/71900ab4-4042-413a-8f3d-38748c2dd8a9n%40googlegroups.com.
