Dimitris Theodorou <dimitris.theodo...@gmail.com> wrote:
> Hi, > > I have a use case where I have two databases, each of which provides a subset > of my models. I have two seperate __abstract__ base classes (each with its > own metadata) that each model inherits from to determine on which database > they belong. To manage separate migrations on each, I will most likely need 2 > separate directories with alembic "versions". > > What's the best way to manage this situation with migrations? If I recognize > my two databases as "main" and "staging", I would want to invoke any alembic > command with an additional argument, such as > > alembic upgrade/current/.. --target_db staging > > that will take care of everything else (i.e. point to the right "versions" > directory, use the right database url, etc.) > > I see a couple of candidates to achieve this but I am not sure which is a > dead end: > > • Use the "multiple bases" feature > (http://alembic.readthedocs.org/en/latest/branches.html#working-with-multiple-bases) > > As long as I create the right labelled branches, this looks like it can > easily substitute the command above with the following > > alembic upgrade --head=staging@head > > I would have to make a mapping of "branch labels" to database urls/engines > inside the env.py, and then determine the right engine from the targeted > head. However, at first glance I cannot get a hold of the targeted head from > the context information available in there. > > > • Use the "multidb" template. While the name of it sounds promising, > this is so sparsely documented that I wouldn't know where to start. > • Use the "-x" argument feature to implement my target db. This looks > straightforward, especially with the example here > (http://alembic.readthedocs.org/en/latest/api.html#alembic.environment.EnvironmentContext.get_x_argument). > However how can I combine it with a seperate "versions" directory? I want to > avoid having to specify both > alembic upgrade --head=staging@head -x target_db=staging > > • Use two totally seperate alembic.ini and alembic directories. That > looks like the simplest way out. > > Any feedback is welcome. the case where you have two databases and two totally separate migration streams has always been handled using the “—name” argument. In your alembic.ini, set up two different named sections and refer to them by name when running the alembic command line. -n NAME, --name NAME Name of section in .ini file to use for Alembic config > > Dimitris > > > > -- > 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-alembic+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- 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-alembic+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
