Bug 1202194

Summary:	[RFE][keystone]: Prefer to check the constraints in the manager level
Product:	Red Hat OpenStack	Reporter:	RHOS Integration <rhos-integ>
Component:	RFEs	Assignee:	RHOS Maint <rhos-maint>
Status:	CLOSED UPSTREAM	QA Contact:
Severity:	low	Docs Contact:
Priority:	unspecified
Version:	unspecified	CC:	markmc, yeylon
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	8.0 (Liberty)
Hardware:	Unspecified
OS:	Unspecified
URL:	https://blueprints.launchpad.net/keystone/+spec/ondelete-cascade
Whiteboard:	upstream_milestone_none upstream_definition_approved upstream_status_implemented
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description RHOS Integration 2015-03-16 04:03:03 UTC

Cloned from launchpad blueprint https://blueprints.launchpad.net/keystone/+spec/ondelete-cascade.

Description:

ForeignKey is used widely in the SQL backend, when  ForeignKey is normally coupled with ondelete parameter, typical values include CASCADE, DELETE and RESTRICT. 

If no value is given for this parameter, "RESTRICT" is default value which means the parent entry can not be deleted before the child entry is removed, or else the error "ERROR 1451" will be thrown when trying to remove the  parent entry first. In order to make the deletion on the parent entry successfully, we have done something in the driver layer, typically, remove the child at first and then remove the parent. It shows "RESTRICT" is useless in this case, so we can migrate the FK definition from "RESTRICT" to "CASCADE", this will help to reducing database round trips.

For those entities which not allow to remove the parent when it has children, it make sense to define the FK with "RESTRICT" parameters, so the behavior will be  consistent between Keystone manager and DB itself.

As to those enties which remove the parent without removing the children at first, this will prone to exceptions if no "CASCADE" is used.  


Specification URL (additional information):

None