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