On Wed, Apr 25, 2012 at 5:17 PM, Vishvananda Ishaya <vishvana...@gmail.com>wrote:
> The main issue is when the relevant tables are moved into a separate > service a la quantum or cinder. We can't keep referential integrity across > multiple databases, so the foreign keys in this case need to be removed. It > leads to an odd situation when there is still an internal implementation in > addition to the external implementation because the internal implementation > no longer has foreign keys. > Sure, there's little you can do in that case. I thought the OP was talking about 2 tables in the same database that were already set up with a foreign key relationship, with the referential integrity checks disabled. > > As an example, we used to have foreign key relationships between instances > and networks. We can no longer have these because we support networks > declared externally. The internal network management now has no > referential integrity, but this is the price we pay for separation of > concerns. We are going through a similar set of relationship-breaking with > the volume code. > Right, those references should be via UUID rather than the integer keys (if the reference is still needed at all). > > > Vish > > On Apr 25, 2012, at 11:02 AM, Doug Hellmann wrote: > > > > On Wed, Apr 25, 2012 at 7:38 AM, Andrew Hutchings > <and...@linuxjedi.co.uk>wrote: > >> On 12/04/12 13:35, J. Daniel Schmidt wrote: >> > While testing our SUSE OpenStack packages we hit a nasty bug and >> reported it >> > as: https://bugs.launchpad.net/keystone/+bug/972502 >> > >> > We found out that the underlying cause was a lack of referential >> integrity[1] >> > using sqlite or mysql. When we tried to reproduce this issue on >> postgresql the >> > usage of foreign keys greatly helped to find the cause. >> >> >From a MySQL prospective that is probably more of an argument to use >> transactions, not foreign keys. >> > > Transactions and referential integrity are related, but not equivalent. > Without referential integrity it's quite easy to commit a transaction that > leaves the database in a logically inconsistent state (it sounds like > that's what was happening in the case described by the OP). > > Is there a technical reason to disable strict referential integrity > checking with MySQL? > > Doug > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > > >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
