> On Nov 21, 2014, at 7:35 PM, Kevin Benton <blak...@gmail.com> wrote: > > This is great! I'm not sure if you have been following some of the discussion > about the separation of vendor drivers in Neutron, but one of the things we > decided was to leave the vendor data models in the main repo so we have a > nice linear migration. > It looks like branching support may solve our problem. However, looking > through the docs I didn't notice anything about where the migration > definitions need to live. Can migrations be sourced from multiple locations > easily?
that’s another TODO, which is https://bitbucket.org/zzzeek/alembic/issue/124/multiple-versions-directories <https://bitbucket.org/zzzeek/alembic/issue/124/multiple-versions-directories>. Skip down to the bottom comments as for the longest time I wasn’t really getting how this would work b.c. the multiple branch thing wasn’t in place. Without that issue and even without the branching thing, you can, right now, have multiple alembic environments entirely separately, sharing only the alembic.ini file, in which you refer to each environment by name, which is what I was getting at in this issue up earlier. Within one database they can have separate alembic_version tables using version_table_name. That means that each environment has its own set of revisions entirely independent of each other, so if there are cross dependencies between these streams, then this approach doesn’t work. With multiple branches in one revision stream as is provided with the new feature, now you have the ability to have cross-dependencies between these streams, if needed. But that means they need to share the env.py since that’s the invocation for them, and needs to be able to run any of those scripts. Having a single env.py as we do now, and just being able to put the actual revision files in multiple places, is very easy, even for Sunday, if we say that we can stick with the single base script_directory, one env.py and one home base, and then just load the actual revision files from multiple places. This would be trivial.
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
