Morgan Fainberg morgan.fainberg at gmail.com
Sun Mar 8 04:19:22 UTC 2015

In general I'd say that cascade is the right approach. There are some very
limited cases where restrict should be used. Overall, I'd like to see less
reliance on FK constraints anywhere. The reason for using Cascade is that
we should be very specific in our code to prevent deletion independent of
the backend (move these checks to the controller level) if we want to
prevent deletion cascades. In short, we should not rely on an
implementation specific detail to know if we can / cannot delete something.


On Sat, Mar 7, 2015 at 7:37 PM, Chen, Wei D <wei.d.chen at intel.com> wrote:

> Hi,
> I did some homework to follow up the inline comment about on delete
> cascade subclauses of the foreign key clause[1], when ' ON
> DELETE CASCADE ' is given, delete a recode from parent table will DELETE
> all the corresponding rows from the CHILD table
> automatically *without any warning*. 'ON DELETE RESTRICT' looks different,
> it will fail complaining about the existing child rows,
> this is the default foreign key relationship behavior, this seems give end
> user a chance to double check the data.
> I did a quick test against the table 'endpoint_group', the output error
> message like below,
> mysql> delete from endpoint_group;
> ERROR 1451 (23000): Cannot delete or update a parent row: a foreign key
> constraint fails (`keystone`.`project_endpoint_group`,
> CONSTRAINT `project_endpoint_group_ibfk_1` FOREIGN KEY
> (`endpoint_group_id`) REFERENCES `endpoint_group` (`id`))
> I am a little confused about two different subclauses as both of them can
> be found in the table definition of SQL backends, it hard
> to say which one is better, is it worthwhile to move all of them to "ON
> [1]
> https://review.openstack.org/#/c/151931/5/keystone/contrib/endpoint_filter/migrate_repo/versions/002_add_endpoint_groups.py
> Best Regards,
> Dave Chen
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150307/81f7709c/attachment.html>

More information about the OpenStack-dev mailing list