On Oct 4, 2014, at 11:24 AM, Clint Byrum <cl...@fewbar.com> wrote: > > Excerpts from Mike Bayer's message of 2014-10-04 08:10:38 -0700: >> >> On Oct 4, 2014, at 1:10 AM, Kevin Benton <blak...@gmail.com> wrote: >> >>> 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. >> >> cross “database” is not typically portable, but cross “schema” is. >> >> different database vendors have different notions of “databases” or >> “schemas”. >> >> if you can get the “other database” to be accessible from the target >> database via “otherdatabase.sometable”, then you’re in. >> >> from SQLAlchemy’s perspective, it’s just a name with a dot. It’s the >> database itself that has to support the foreign key at the scope you are >> shooting for. >> > > All true, however, there are zero guarantees that databases will be > hosted on the same server, and typically permissions are setup to prevent > cross-schema joins.
the impression I’ve gotten so far is that they are looking to have different sets of database tables isolated into groups that can be migrated independently, and rather than using multiple alembic version tables, they’d go with this approach. This to me means that on a postgresql backend these would just be individual sub-schemas, and on a MySQL backend would be other databases that are limited to being on the same host (which is MySQL’s version of “schemas”, in that the “CREATE SCHEMA” command is a synonym for “CREATE DATABASE"). > > Typically we use the public API's when we want to access data in a > different application. The database is a private implementation detail > of each application. I was just having a discussion on IRC the other day with a Neutron dev stating that they’d like to break out several parts of Neutron into “plugins”, which would have their own database tables but still linked to the database tables of the core Neutron application. If this is the case, within an architecture like that you’d have different sub-applications cross-accessing databases. > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
