Branching

[Walter King]

We've been using branching for a bit and it mostly works the way we want.  Twice now we've run into the error when upgrading heads:

AssertionError: Can't do an UPDATE because downrevision is ambiguous

The policy we've had is when you create a new revision, if theres a branch then you must first make a merge on your branch.  So in this case, two people branch off of three heads, they make an identical merge revision, and have a child each off the merge.  When you look at the history it seems like it does what youd expect, makes two heads, but it wont apply.

 

33e21c000cfe -> 178d4e761bbd (head), 

2bef33cb3a58, 3904558db1c6, 968330f320d -> 33e21c000cfe (mergepoint), Merging

46c99f866004 -> 18f46b42410d (head), 

2bef33cb3a58, 3904558db1c6, 968330f320d -> 46c99f866004 (mergepoint), Merging

f0fa4315825 -> 3904558db1c6 (branchpoint), 

Any pointers on how to avoid this?

Thanks!

[Mike Bayer]

let's start with what you have there:

        33e21c000cfe -> 178d4e761bbd (head),
        2bef33cb3a58, 3904558db1c6, 968330f320d -> 33e21c000cfe (mergepoint)

        46c99f866004 -> 18f46b42410d (head),
        2bef33cb3a58, 3904558db1c6, 968330f320d -> 46c99f866004 (mergepoint)

        f0fa4315825 -> 3904558db1c6 (branchpoint),


let me substitute names that are more human friendly:

        A -> B2

        B1, B2, B3 -> C1
        B1, B2, B3 -> C2

        C1 -> D1 (head),

        C2 -> D2 (head),

So I think, that's not all the history?  Doesn't matter for the test case I'm making so I assume it's something more like this:

        A -> B1,
        A -> B2,
        A -> B3,

        B1, B2, B3 -> C1
        B1, B2, B3 -> C2

        C1 -> D1 (head),

        C2 -> D2 (head),

that is, you started with a single root, I'm assuming.

The steps to upgrade from A to D1/D2 come out normally:

upgrade a -> b3, b3
upgrade a -> b1, b1
upgrade a -> b2, b2
upgrade b1, b2, b3 -> c2, c2
upgrade c2 -> d2, d2
upgrade b1, b2, b3 -> c1, c1
upgrade c1 -> d1, d1

so those states have to be each represented in alembic_version individually.  Logging those transitions they come out as:

DEBUG:alembic.migration:update a to b3
DEBUG:alembic.migration:new branch insert b1
DEBUG:alembic.migration:new branch insert b2
DEBUG:alembic.migration:merge, delete ['b1', 'b2'], update b3 to c2
DEBUG:alembic.migration:update c2 to d2

where "update", "insert", and "delete" mean that's the SQL we're going to run on alembic_version.

It then crashes on b1, b2, b3 -> c1, because it thinks it's supposed to to an UPDATE, but there is no row to UPDATE because all three of b1, b2, b3 are gone.  What it really should do here is an INSERT of c1.     The logic that asks, "should we insert a row?" looks to see if the revision (in this case c1) has multiple entries as descendants, in which case it's a MERGE point, as c1 is.   the MERGE operation is currently coded in all cases to expect that when we reach a MERGE point, all of its ancestors are definitely there, else how else did we arrive at a MERGE point?      But in this case you've taken the same three revs and merged them twice, in effect merged and branched at the same time.  This was never expected.  

The internal mechanics ask the question, "if we have more than one anscestor, we're a MERGE point, therefore we definitely aren't INSERTing an identifier".  They also assert that, "if we have only one anscestor, we're not a MERGE point, so if our ansestor *is* in the current heads, we do an UPDATE and if it isn't, we do an INSERT".     The logic here can be simplified, such that, "if none of our ancestors are in the current heads, we do an INSERT".

I've captured this all in https://bitbucket.org/zzzeek/alembic/issue/297/transition-from-multiple-revs-to-one-as-a where the logic has been opened up for mergepoints such that an INSERT is considered to be OK under these conditions, that is in c75be37640a19990d385a805 and will be out in 0.7.6.

Any pointers on how to avoid this?

Thanks!

--
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.
For more options, visit https://groups.google.com/d/optout.

[Mike Bayer]

On 5/3/15 8:19 PM, Mike Bayer wrote:

I've captured this all in https://bitbucket.org/zzzeek/alembic/issue/297/transition-from-multiple-revs-to-one-as-a where the logic has been opened up for mergepoints such that an INSERT is considered to be OK under these conditions, that is in c75be37640a19990d385a805 and will be out in 0.7.6.

If you can confirm this fix solves your issue, that would give me the confidence to put out the next release of Alembic immediately.

[Walter King]

Awesome, that was fast!  I've been able to run it successfully with master.

Thanks!

--
You received this message because you are subscribed to a topic in the Google Groups "sqlalchemy-alembic" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sqlalchemy-alembic/4mDpZYPHWXc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sqlalchemy-alem...@googlegroups.com.