openstack team mailing list archive

[Doug Hellmann <doug.hellmann@xxxxxxxxxxxxx>]

On Wed, Apr 25, 2012 at 5:17 PM, Vishvananda Ishaya
<vishvananda@xxxxxxxxx>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 <andrew@xxxxxxxxxxxxxxx>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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
>