Wrong assumption about bases and working in parallel

[avanderm]

Hey,

I was under the wrong impression that with multiple bases, teams could work in parallel, focusing on the branches that fall under their responsibility. I was wrong, since if one team adds a new revision locally and decides to upgrade in a development environment, this locks the environment for other users that do not have this revision locally and are trying to upgrade a different base (not until the first team downgrades back to a shared revision).

With this in mind, I'm looking for alternatives, so that teams can work in parallel. My best shot it seems is to use a different version_table per base. I would like to this in a more programmatic version in env.py. I am however stuck in figuring out which branch is referred to during an upgrade. The context.get_revision_argument() returns identifiers. Does alembic have some methods, ..., to translate this to a branch label?

[zzzeek]

usually when teams work in parallel but on different versions of a schema they use their own development database. if you have teams that are all deploying non-merged code to a shared development database, that seems like it would cause a lot more problems than just that.

if you want to maintain completely separate versioning streams that have no dependencies on each other, then you could set up different environment names in your alembic.ini and the versioning files as well would be in separate sub-directories. This use case is demonstrated at https://alembic.sqlalchemy.org/en/latest/cookbook.html#run-multiple-alembic-environments-from-one-ini-file .

but if these separate teams are working on branches that eventually interact with each other, a shared development database would need to be exposed to only code that's been merged into the main branch. code that's still in dev branches shouldn't be deployed to a common dev database.

[avanderm]

Yeah that makes sense, I prefer to use the new bases approach. Our developers can be a bit forgetful, but the chance to omit special code and hacks is always welcome. Probably easier to clean up temp databases on a cluster anyways from time to time. Thanks for alembic and the advise!