<br><br>On Monday, March 9, 2015, Mike Bayer <<a href="mailto:mbayer@redhat.com">mbayer@redhat.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
Wei D <<a href="javascript:;" onclick="_e(event, 'cvml', 'wei.d.chen@intel.com')">wei.d.chen@intel.com</a>> wrote:<br>
<br>
> +1,<br>
><br>
><br>
><br>
> I am fan of checking the constraints in the controller level instead of relying on FK constraints itself, thanks.<br>
<br>
Why shouldn’t the storage backends, be they relational or not, be tasked<br>
with verifying integrity of data manipulations? If data integrity rules are<br>
pushed out to the frontend, the frontend starts implementing parts of the<br>
backend. Other front-ends to the same persistence backend might not have the<br>
same rule checks, and you are now wide open for invalid data to be<br>
persisted.<br>
<br>
Front-ends should of course be encouraged to report on a potential issue in<br>
integrity before proceeding with an operation, but IMO the backend should<br>
definitely not allow the operation to proceed if the frontend fails to check<br>
for a constraint. Persistence operations in which related objects must also<br>
be modified in response to a primary object (e.g. a CASCADE situation),<br>
else integrity will fail, should also be part of the backend, not the front end.<br>
<br>
<br>
<br></blockquote><div><br></div><div>You are assuming data is stored in an all SQL environment. In keystone it is highly unlikely that you can make this assumption. When you discuss users, groups, projects, domains, roles, assignments, etc... All of these could be crossing SQL, LDAP, MongoDB, etc. in short, do not assume you are even talking the same language.  This is why FKs are of minimal benefit to us. The manager layer contains the business logic (and should) to handle the cross-referencing of objects. The only FKs we have are for uuid/PK identitifiers at the moment (afaik), these are/should-be immutable. </div><div><br></div><div>So tl;dr, we have an architecture that is not conducive to foreign keys, and therefore should not use them beyond bare-minimums, instead rely on the manager to do business logic. This is not the case for all OpenStack projects.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
> Best Regards,<br>
><br>
> Dave Chen<br>
><br>
><br>
><br>
> From: Morgan Fainberg [mailto:<a href="javascript:;" onclick="_e(event, 'cvml', 'morgan.fainberg@gmail.com')">morgan.fainberg@gmail.com</a>]<br>
> Sent: Monday, March 09, 2015 2:29 AM<br>
> To: David Stanek; OpenStack Development Mailing List (not for usage questions)<br>
> Subject: Re: [openstack-dev] [Keystone]ON DELETE RESTRICT VS ON DELETE CASCADE<br>
><br>
><br>
><br>
> On March 8, 2015 at 11:24:37 AM, David Stanek (<a href="javascript:;" onclick="_e(event, 'cvml', 'dstanek@dstanek.com')">dstanek@dstanek.com</a>) wrote:<br>
><br>
><br>
> On Sun, Mar 8, 2015 at 1:37 PM, Mike Bayer <<a href="javascript:;" onclick="_e(event, 'cvml', 'mbayer@redhat.com')">mbayer@redhat.com</a>> wrote:<br>
><br>
> can you elaborate on your reasoning that FK constraints should be used less<br>
> overall?  or do you just mean that the client side should be mirroring the same<br>
> rules that would be enforced by the FKs?<br>
><br>
><br>
> I don't think he means that we will use them less.  Our SQL backends are full of them.  What Keystone can't do is rely on them because not all implementations of our backends support FKs.<br>
><br>
> 100% spot on David. We support implementations that have no real concept of FK and we cannot assume that a cascade (or restrict) will occur on these implementations.<br>
><br>
><br>
><br>
> —Morga<br>
><br>
><br>
><br>
> --<br>
><br>
> David<br>
> blog: <a href="http://www.traceback.org" target="_blank">http://www.traceback.org</a><br>
> twitter: <a href="http://twitter.com/dstanek" target="_blank">http://twitter.com/dstanek</a><br>
><br>
> www: <a href="http://dstanek.com" target="_blank">http://dstanek.com</a><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote>