We have two schema variants for now, one is a legacy schema which we want
to retire eventually but it is still used by many installations. Newer
variant provides new features, and installations that require those new
features have to migrate immediately. OTOH we do not want to require
everyone
I'm quite curious about why you need to maintain all these different
versions of the same database. Like in code, you branch out to be able to
do development in parallel without interfering other development, and
eventually you merge back. But here it seems you want to keep multiplying
the number
That might work but would be a nightmare to manage. Basically every new
"switch" introduces new branch that will never be merged and new migrations
need to be added to every relevant branch. I think that it can also result
in combinatorial explosion of branches if later switching is attempted.
I see... Ok, then I think that what you are actually doing is not going
back b1, b2, etc., but something slightly different, which we could name
c1, c2, etc. These migrations are going to be very similar to the "b"
branch, so you can reuse probably a good amount of code, but adapting them
to start
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
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 wrote: