Does sqlalchemy have good support for cross-database foreign keys? I was under the impression that they cannot be implemented with the normal syntax and semantics of an intra-database foreign-key constraint.
On Fri, Oct 3, 2014 at 5:25 PM, Ivar Lazzaro <ivarlazz...@gmail.com> wrote: > Hi, > > Following up the latest GBP team meeting [0][1]: > > As we keep going with our Juno stackforge implementation [2], although the > service is effectively a Neutron extension, we should avoid breaking > Neutron's migration chain by adding our model on top of it (and > subsequently changing Neutron's HEAD [3]). If we do that, upgrading from > Juno to Kilo will be painful for those who have used GBP. > > There are roughly a couple of possibilities for reaching this goal: > > 1) Using a separate DBs with separate migration chain; > 2) Using the same DB with separate chain (and different alembic version > table). > > Personally I prefer the option 1, moving to a completely different > database while leveraging cross database foreign keys. > > Please let me know your preference, or alternative solutions! :) > > Cheers, > Ivar. > > [0] > http://eavesdrop.openstack.org/meetings/networking_policy/2014/networking_policy.2014-09-25-18.02.log.html > [1] > http://eavesdrop.openstack.org/meetings/networking_policy/2014/networking_policy.2014-10-02-18.01.log.html > [2] https://github.com/stackforge/group-based-policy > [3] https://review.openstack.org/#/c/123617/ > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Kevin Benton
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev