Supporting multiple versions with ability to downport to old versions

[pythonweb2]

I am hoping to support multiple versions of an app, but I am having a hard time thinking of how Alembic would be able to support database patches to prior versions.

To give an example, lets say I have App v1.1, which has revisions that look like this:

             A
        /        \
base  -      B   -   v1.1
        \        /
             C

So three migrations were made, then merged and applied for the app. Then let's say I start work on App v1.2, and Now my migrations look like this:

             A                   D
        /        \            /      \
base   -     B    -   v1.1  -    E   -   v2.2
        \        /            \      /
             C                   F

However, let's say that revision D was a bug fix, and I need the SQL schema changes in v1.1. What can I do?

If I apply the changes via a SQL script to all the products that are on V1.1, it will fix the issue, but when it comes time to upgrade them to v1.2, the migrations are now broken, because one of them was already applied to the V1.1 databases.

In some other projects (such as Django), I might be able to get around this, because rather than the version table tracking where I am in history, it instead tracks what has already been applied. So theoretically, I could apply the revision in V1.1, and not have my migrations break when I eventually upgrade the app to V1.2 (because it would skip applying the bug fix migration, since it was already applied).

Is there something that I am missing? I don't see an easy way to address this, and from looking at issues/discussions online, I haven't seen this brought up. However, I may be overlooking something simple.

[zzzeek]

I am hoping to support multiple versions of an app, but I am having a hard time thinking of how Alembic would be able to support database patches to prior versions.

to clarify, you mean backports, OK.

To give an example, lets say I have App v1.1, which has revisions that look like this:

             A
        /        \
base  -      B   -   v1.1
        \        /
             C

So three migrations were made, then merged and applied for the app. Then let's say I start work on App v1.2, and Now my migrations look like this:

             A                   D
        /        \            /      \
base   -     B    -   v1.1  -    E   -   v2.2
        \        /            \      /
             C                   F

However, let's say that revision D was a bug fix, and I need the SQL schema changes in v1.1. What can I do?

well v1.1, you'd be releasing v1.1.2, so you'd make D against 1.1 as you did for v1.1.2 and have that lead up to v1.1.2

If I apply the changes via a SQL script to all the products that are on V1.1, it will fix the issue, but when it comes time to upgrade them to v1.2, the migrations are now broken, because one of them was already applied to the V1.1 databases.

you'd need to forwards port into 2.2 a mechanism to not re-apply D,which could be that you forwards-port the 1.1 -> D -> 1.1.2 stream into 2.2. Or otherwise modfy 2.2 so that it expects D might be present already.

In some other projects (such as Django), I might be able to get around this, because rather than the version table tracking where I am in history, it instead tracks what has already been applied. So theoretically, I could apply the revision in V1.1, and not have my migrations break when I eventually upgrade the app to V1.2 (because it would skip applying the bug fix migration, since it was already applied).

that sounds like a great feature.

Is there something that I am missing? I don't see an easy way to address this, and from looking at issues/discussions online, I haven't seen this brought up. However, I may be overlooking something simple.

other than "use django", not really, sorry :)

[pythonweb2]

@zzzeek What do you think about a strategy of not merging when releasing a version and instead using alembic upgrade heads?

So then as long as the backported change was independent, I could then apply it in my prior version, and have a history that it was applied.

The strategy would look like this perhaps:

          A  -> 
        /
base  - B ->    alembic upgrade heads -> v1.1
        \
          C -> 

Then when I do development for the second version, it now looks like this

But this time, since Iidn't merge it, it functions similarly to django, since now the alembic_version table keeps track of what revisions (heads) I have already applied.

This seems like a way to mimic what Django does, does that seem valid?

[zzzeek]

@zzzeek What do you think about a strategy of not merging when releasing a version and instead using alembic upgrade heads?

So then as long as the backported change was independent, I could then apply it in my prior version, and have a history that it was applied.

that would work. you'd still need to have anticipated that when you first made the revision for the 2.x series though.

But this time, since I didn't merge it, it functions similarly to django, since now the alembic_version table keeps track of what revisions (heads) I have already applied.

well you are taking the D stream and keeping it independent of your main release stream, which is fine, it means that stream works independently of your 1.1 -> 1.1.2 -> 2.0 stream.

This seems like a way to mimic what Django does, does that seem valid?

I've never looked at what Django does. I just keep hearing about how much better it is from every angle :) on this end their model would be an "Alembic 2.0" and I dont have resources to undertake that.

[pythonweb2]

My apologies, I really wasn't trying to compare Django to Alembic and put down the project in any way. SQLAlchemy/Alembic are great libraries and not as tightly coupled as Django. I was just wondering if there was a way to accomplish this particular way of versioning things.

[zzzeek]

oh no worries at all! Alembic for me is something I had to write out of necessity, not to really compete with anything. Comparisons to Django don't really "ding" me at all because Alembic was never intended to be automated at all, and it's already way more feature-filled than I ever intended.

I'd love it to have something that competes with Django's revisioning model on top of it, but it looks like an entirely different way of approaching the problem which I suspect might be at least somewhat coupled to Django's less flexible schema capabilities overall.

[CaselIT]

Hi,

Can't you use two branches, one for new features and one for bugfixes?

             A
        /        \
base  -      B   -   v1.1
        \        /
             C

base_bugfix - <no migration to apply, just an empty base one>

You then add D that's a bugfix you end up with these two state
The v2.2 version looks like this

             A                   
        /        \           
base   -     B    -   v1.1  -    E   -   v2.2
        \        /            \      /
             C                   F

base_bugix -  D 

The v1.1.1 (assuming the fix was released as version 1.1.1)

            A
        /        \
base  -      B   -   v1.1
        \        /
             C

base_bugfix - D

When you update the application to versio 2.2 the migration D is already there so alembic will skip it