Clint Byrum <cl...@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): http://en.wikipedia.org/wiki/Consistency_%28database_systems%29 > > 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. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
