Running migrations for all databases using different metadata #1403
Replies: 1 comment 5 replies
-
if you are using the i dont have a clear picture of what you have so far since your example does not show any "for loop" or what One is, use the command API directly and make your own front-end that does the things you want, in this case just runs the desired command multiple times with different configs This is the safe / easy / maybe a little tedious way to go but it's very simple and Alembic isn't made to jump through any kind of hoops it was not designed for. The other is more like what you have already, which I think can work, but what you need to do specifically for the autogenerate case (and likely not for the upgrade/downgrade case) is set version_locations at config time to have all of the target directories present at once in a list; this just makes it possible to refer to any specific version_location later on. Then, when each autogenerate runs, you need to set the MigrationScript.version_script to the path you want for each autogenerate run. You can intercept MigrationScript using a process_revision_directives hook. then when the "revision" command does that single step to write all the files, it will deposit them into the individual directories named in each MigrationScript. |
Beta Was this translation helpful? Give feedback.
-
Hello, I need to generate migrations for multiple databases and upgrade them.
Ideally I would want to be able to do autogeneration and upgrades with a single command (
alembic revision --autogenerate
, etc) without having to run that separately for each database.To achieve that I've tried to run
run_migrations
function in a for loop with different arguments (db connection, metadata, etc):here I'm trying to override
version_locations
to a different subdirectory depending on the config, but it seems like alembic only generates revisions afterenv.py
is done executing.To work around that I decided to use the
-x
argument and pass db I need to migrate into it to select a_MigrationConfig
I need. This isn't quite the desired behavior, and I don't think built-inmultidb
template solves it either (since I want each db to have it's own Metadata), so I'm wondering if there's a solution for this problem. It seems like with this configuration migrations themselves should work fine, but revision autogeneration does not.Beta Was this translation helpful? Give feedback.
All reactions