Open Stack

Excerpts from Mike Bayer's message of 2015-03-10 08:35:23 -0700:
> 
> Mike Bayer <mbayer at redhat.com> 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.