<div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Apr 25, 2012 at 7:38 AM, Andrew Hutchings <span dir="ltr"><<a href="mailto:andrew@linuxjedi.co.uk" target="_blank">andrew@linuxjedi.co.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 12/04/12 13:35, J. Daniel Schmidt wrote:<br>
> While testing our SUSE OpenStack packages we hit a nasty bug and reported it<br>
> as:  <a href="https://bugs.launchpad.net/keystone/+bug/972502" target="_blank">https://bugs.launchpad.net/keystone/+bug/972502</a><br>
><br>
> We found out that the underlying cause was a lack of referential integrity[1]<br>
> using sqlite or mysql. When we tried to reproduce this issue on postgresql the<br>
> usage of foreign keys greatly helped to find the cause.<br>
<br>
</div>>From a MySQL prospective that is probably more of an argument to use<br>
transactions, not foreign keys.<br></blockquote><div><br></div><div>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).</div>
<div><br></div><div>Is there a technical reason to disable strict referential integrity checking with MySQL?</div><div><br></div><div>Doug</div><div><br></div></div></div>