Excerpts from Mike Bayer's message of 2015-03-10 08:35:23 -0700: > > Mike Bayer <[email protected]> wrote: > > > > >> 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. > > I apologize for my snark here. The above code is wrong, and I think it is > obviously wrong. People working on this code should be familiar with > SQLAlchemy basics (at least having read the ORM tutorial), and that includes > the very easy to use features of relationship management. >
No need to apologize, and I appreciate very much what point you're making. They have a benefit, and I didn't mean to imply they don't when I first suggested they be disabled and dropped. The point I'm making is, their benefits can often be outweighed by their costs. Keystone is already feeling a bit of the cost of rigidity with a separation of things into disparate backends. Anyway, I hope we can end this with a better understanding for everyone. They're not always a good idea, and they're not always a bad idea. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
