Mike Bayer mbayer at redhat.com
Tue Mar 10 14:14:24 UTC 2015

Clint Byrum <clint at fewbar.com> wrote:

> Please try to refrain from using false equivalence. ACID stands for
> Atomicity, Consistency, Isolation, Durability. Nowhere in there does it
> stand for "referential integrity”. 

This point is admittedly controversial as I’ve had this debate before, but
it is common that the database concept of integrity constraints is
considered under the umbrella of “consistency” as one of the facets of this
guarantee. Just check the second sentence of Wikipedia’s page (which I have
been told is itself incorrect, which if so, I would greatly appreciate
someone editing this page as well as their ACID page to remove all
references to “constraints, cascades, and triggers” and perhaps clarify that
these concepts have nothing to do with ACID):

> I'm not entirely sure what you've said above actually prevents coders
> from relying on the constraints. Being careful about deleting all of the
> child rows before a parent is good practice. I have seen code like this
> in the past though:
> try:
>  parent.delete()
> except ForeignKeyFailure:
>  parent.children.delete()
>  parent.delete()
> This means if you don't have the FK's, you may never delete the
> children. Is this a bug? YES. Is it super obvious that it is the wrong
> thing to do? No.

So the point you’re making here is that, if foreign key constraints are
removed, poorly written code might silently fail. I’m glad we agree this is
an issue!  It’s the only point I’m making.

More information about the OpenStack-dev mailing list