<div dir="ltr">I posted a patch that implements the "Different DB Different Chain" approach [0].<div>That does not mean that this approach is the chosen one! It's just to have a grasp of what the change looks like. </div><div><br></div><div>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.</div><div><br></div><div>One thing I'm particularly interested about is to hear packagers opinions about which approach would be the preferred one: Same DB or Different?</div><div>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?</div><div><br></div><div>Thanks,</div><div>Ivar.</div><div><br></div><div><span>[0] <a class="linkclass" href="https://review.openstack.org/#/c/126383/">https://review.openstack.org/#/c/126383/</a></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 6, 2014 at 11:09 AM, Ivar Lazzaro <span dir="ltr"><<a href="mailto:ivarlazzaro@gmail.com" target="_blank">ivarlazzaro@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-family:arial,sans-serif;font-size:13px">I believe Group-based Policy (which this thread is about) will use the Neutron</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">database configuration for its dependent database.</span><br style="font-family:arial,sans-serif;font-size:13px"><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">If Neutron is configured for:</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">  connection = mysql://user:pass@locationX:</span><span style="font-family:arial,sans-serif;font-size:13px">3306/neutron</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">then GBP would use:</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">  connection = mysql://user:pass@locationX:</span><span style="font-family:arial,sans-serif;font-size:13px">3306/neutron_gbp</span></blockquote><div><br></div></span><div>That's correct, that would be the likely approach if we go with the "different schema" route.</div><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="font-family:arial,sans-serif;font-size:13px">if you can get the “other database” to be accessible from the target database via “otherdatabase.sometable”, then you’re in.</div><div style="font-family:arial,sans-serif;font-size:13px">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.</div></blockquote><div><br></div></span><div>I'm experimenting this approach with our code and it seems to be the case. '</div><div>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.</div><div> </div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Oct 4, 2014 at 8:54 AM, Henry Gessau <span dir="ltr"><<a href="mailto:gessau@cisco.com" target="_blank">gessau@cisco.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>Clint Byrum <<a href="mailto:clint@fewbar.com" target="_blank">clint@fewbar.com</a>> wrote:<br>
><br>
> Excerpts from Mike Bayer's message of 2014-10-04 08:10:38 -0700:<br>
>><br>
>> On Oct 4, 2014, at 1:10 AM, Kevin Benton <<a href="mailto:blak111@gmail.com" target="_blank">blak111@gmail.com</a>> wrote:<br>
>><br>
>>> 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.<br>
>><br>
>> cross “database” is not typically portable, but cross “schema” is.<br>
>><br>
>> different database vendors have different notions of “databases” or “schemas”.<br>
>><br>
>> if you can get the “other database” to be accessible from the target database via “otherdatabase.sometable”, then you’re in.<br>
>><br>
>> 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.<br>
>><br>
><br>
> All true, however, there are zero guarantees that databases will be<br>
> hosted on the same server, and typically permissions are setup to prevent<br>
> cross-schema joins.<br>
<br>
</span>I believe Group-based Policy (which this thread is about) will use the Neutron<br>
database configuration for its dependent database.<br>
<br>
If Neutron is configured for:<br>
  connection = mysql://user:pass@locationX:3306/neutron<br>
then GBP would use:<br>
  connection = mysql://user:pass@locationX:3306/neutron_gbp<br>
<span><br>
> Typically we use the public API's when we want to access data in a<br>
> different application. The database is a private implementation detail<br>
> of each application.<br>
<br>
</span>Currently GPB is very tightly coupled to Neutron.<br>
<div><div><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>