Open Stack

I posted a patch that implements the "Different DB Different Chain"
approach [0].
That does not mean that this approach is the chosen one! It's just to have
a grasp of what the change looks like.

The "Same DB different chain" solution is much simpler to implement
(basically you just specify a different version table in the alembic
environment) so I haven't posted anything for that.

One thing I'm particularly interested about is to hear packagers opinions
about which approach would be the preferred one: Same DB or Different?
Also, on the line of Bob's comment in my patch, is there any kind of
compatibility or performance issue anyone is aware of about in using cross
schema FKs?

Thanks,
Ivar.

[0] https://review.openstack.org/#/c/126383/

On Mon, Oct 6, 2014 at 11:09 AM, Ivar Lazzaro <ivarlazzaro at gmail.com> wrote:

> I believe Group-based Policy (which this thread is about) will use the
>> Neutron
>> database configuration for its dependent database.
>>
>> If Neutron is configured for:
>>   connection = mysql://user:pass@locationX:3306/neutron
>> then GBP would use:
>>   connection = mysql://user:pass@locationX:3306/neutron_gbp
>
>
> That's correct, that would be the likely approach if we go with the
> "different schema" route.
>
> 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.
>>
>
> I'm experimenting this approach with our code and it seems to be the case.
> '
> I feel that having the constraint of pointing the same database connection
> with a different schema is pretty acceptable given how tight is GBP to
> Neutron.
>
>
> On Sat, Oct 4, 2014 at 8:54 AM, Henry Gessau <gessau at cisco.com> wrote:
>
>> Clint Byrum <clint at 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 <blak111 at 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.
>>
>> I believe Group-based Policy (which this thread is about) will use the
>> Neutron
>> database configuration for its dependent database.
>>
>> If Neutron is configured for:
>>   connection = mysql://user:pass@locationX:3306/neutron
>> then GBP would use:
>>   connection = mysql://user:pass@locationX:3306/neutron_gbp
>>
>> > 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.
>>
>> Currently GPB is very tightly coupled to Neutron.
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141007/694a0e12/attachment.html>