Open Stack

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 <ivarlazzaro at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141003/fa9fcb4a/attachment.html>