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 

> 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

Reply via email to