Downgrade for a git branch

[openbrian]

My overall goal is to generate a CI test to make sure that when my developer team branches the codebase and generates a few database revisions, that the downgrade() methods actually returns the database to the structural state it was in before the upgrades happened. These branches are typically short lived, but some may be long lived.

We generally do not label our revision branches. Maybe that's an option. If so, we would then need another test to make sure every revision contains a branch label. That's easy enough to do. What would the downgrade command look like for this and does the merge revision use the branch label?

But I thought this should be doable without branch labels. With CI I'm able to generate (1) a full list of revisions, (2) the revisions that are added in this pull request, and consequently (3) the head revision on the PR target (main).

Our team is often updating main, so there are often merge revisions. Here's the simple and complex cases.

I expect that when I run alembic downgrade main-2, that main-2 becomes the new head. Meaning both main-merge, and feature-1 are downgraded. But feature-1 remains and only main-merge was downgraded. I'm not sure if that's intended or a bug. I scanned test_version_traversal.py but don't really see this scenario.

I also forked and added a test with my expectation and it fails.

In general, a feature branch could have several revisions and merges, especially if the developer rebases based on main.

Similarly when I run alembic downgrade main-4, I expect that main-merge, feature-2, feature-rebase-merge-1, and feature-1 are downgraded.

In general I expect the rule to be: downgrade all the migrations that don't lead to the specified head. If the CLI doesn't permit this, is there a way to do this manually with python?

Side suggestion: If the user wants to leave multiple heads, that can be specified as arguments alembic downgrade head-1,head-2.

If you're interested in exploring this approach, let me know. Just point me to where to get started.

[CaselIT]

Hi,

I expect that when I run alembic downgrade main-2, that main-2 becomes the new head. Meaning both main-merge, and feature-1 are downgraded. But feature-1 remains and only main-merge was downgraded. I'm not sure if that's intended or a bug. I scanned test_version_traversal.py but don't really see this scenario.

That's expected, since there is no connection between main-2 and feature-1 so alembic will just run the migration to make one of the heads main-2

similarly in you other case I would expect that the final state is 2 heads: main-4 and feature-1.

downgrade currently does "the target revision is one of the heads" while you want "the target revision is the only head".

@zzzeek do you think it would make sense as an option to downgrade / different command?