Re: [openstack-dev] [Keystone]ON DELETE RESTRICT VS ON DELETE CASCADE

Adam Young wrote: > On 03/10/2015 10:23 AM, Mike Bayer wrote: >> if *that’s* >> what you mean, that’s known as a “polymorphic foreign key”, and >> it is not actually a foreign key at all, it is a terrible antipattern >> started by >> the PHP/Rails community and carried forth by projects like

Re: [openstack-dev] [Keystone]ON DELETE RESTRICT VS ON DELETE CASCADE

On 03/10/2015 10:23 AM, Mike Bayer wrote: if*that’s* what you mean, that’s known as a “polymorphic foreign key”, and it is not actually a foreign key at all, it is a terrible antipattern started by the PHP/Rails community and carried forth by projects like Django. A) Heh. it is much, much older

Re: [openstack-dev] [Keystone]ON DELETE RESTRICT VS ON DELETE CASCADE

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

Re: [openstack-dev] [Keystone]ON DELETE RESTRICT VS ON DELETE CASCADE

Mike Bayer 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.delet

Re: [openstack-dev] [Keystone]ON DELETE RESTRICT VS ON DELETE CASCADE

Adam Young wrote: > On 03/09/2015 01:26 PM, Mike Bayer wrote: >> Im about -1000 on disabling foreign key constraints. > So was I. We didn't do it out of performance. > > Since I am responsible for tipping over this particular cow, let me explain. > > No, is too much. Let me sum up. > > In t

Re: [openstack-dev] [Keystone]ON DELETE RESTRICT VS ON DELETE CASCADE

Clint Byrum wrote: > > Please try to refrain from using false equivalence. ACID stands for > Atomicity, Consistency, Isolation, Durability. Nowhere in there does it > stand for "referential integrity”. This point is admittedly controversial as I’ve had this debate before, but it is common th

Re: [openstack-dev] [Keystone]ON DELETE RESTRICT VS ON DELETE CASCADE

On 03/09/2015 01:26 PM, Mike Bayer wrote: Im about -1000 on disabling foreign key constraints. So was I. We didn't do it out of performance. Since I am responsible for tipping over this particular cow, let me explain. No, is too much. Let me sum up. In the murky past, Keystone was primarily

Re: [openstack-dev] [Keystone]ON DELETE RESTRICT VS ON DELETE CASCADE

Excerpts from Mike Bayer's message of 2015-03-09 17:26:36 -0700: > > Clint Byrum wrote: > > > > > So I think I didn't speak clearly enough here. The benchmarks are of > > course needed, but there's a tipping point when write activity gets to > > a certain level where it's cheaper to let it get

Re: [openstack-dev] [Keystone]ON DELETE RESTRICT VS ON DELETE CASCADE

Clint Byrum wrote: > > So I think I didn't speak clearly enough here. The benchmarks are of > course needed, but there's a tipping point when write activity gets to > a certain level where it's cheaper to let it get a little skewed and > correct asynchronously. This is not unique to SQL, this

Re: [openstack-dev] [Keystone]ON DELETE RESTRICT VS ON DELETE CASCADE

Excerpts from Mike Bayer's message of 2015-03-09 10:26:37 -0700: > > Clint Byrum wrote: > > > Excerpts from David Stanek's message of 2015-03-08 11:18:05 -0700: > >> On Sun, Mar 8, 2015 at 1:37 PM, Mike Bayer wrote: > >> > >>> can you elaborate on your reasoning that FK constraints should be u

Re: [openstack-dev] [Keystone]ON DELETE RESTRICT VS ON DELETE CASCADE

> > > Dave Chen > > > > > > > > From: Morgan Fainberg [mailto:morgan.fainb...@gmail.com] > > Sent: Monday, March 09, 2015 2:29 AM > > To: David Stanek; OpenStack Development Mailing List (not for usage > > questions) > > Subject: Re: [openstac

Re: [openstack-dev] [Keystone]ON DELETE RESTRICT VS ON DELETE CASCADE

; > > > From: Morgan Fainberg [mailto:morgan.fainb...@gmail.com ] > > Sent: Monday, March 09, 2015 2:29 AM > > To: David Stanek; OpenStack Development Mailing List (not for usage > questions) > > Subject: Re: [openstack-dev] [Keystone]ON DELETE RESTRICT VS ON DELETE >

Re: [openstack-dev] [Keystone]ON DELETE RESTRICT VS ON DELETE CASCADE

Clint Byrum wrote: > Excerpts from David Stanek's message of 2015-03-08 11:18:05 -0700: >> On Sun, Mar 8, 2015 at 1:37 PM, Mike Bayer wrote: >> >>> can you elaborate on your reasoning that FK constraints should be used less >>> overall? or do you just mean that the client side should be mirr

Re: [openstack-dev] [Keystone]ON DELETE RESTRICT VS ON DELETE CASCADE

On Sun, Mar 8, 2015 at 10:28 PM, Chen, Wei D wrote: > +1, > > > > I am fan of checking the constraints in the controller level instead of > relying on FK constraints itself, thanks. > The Keystone controllers shouldn't do any business logic. This should be in the managers. The controllers should

Re: [openstack-dev] [Keystone]ON DELETE RESTRICT VS ON DELETE CASCADE

; OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [Keystone]ON DELETE RESTRICT VS ON DELETE CASCADE > > > > On March 8, 2015 at 11:24:37 AM, David Stanek (dsta...@dstanek.com) wrote: > > > On Sun, Mar 8, 2015 at 1:37 PM

Re: [openstack-dev] [Keystone]ON DELETE RESTRICT VS ON DELETE CASCADE

Excerpts from David Stanek's message of 2015-03-08 11:18:05 -0700: > On Sun, Mar 8, 2015 at 1:37 PM, Mike Bayer wrote: > > > can you elaborate on your reasoning that FK constraints should be used less > > overall? or do you just mean that the client side should be mirroring the > > same > > rule

Re: [openstack-dev] [Keystone]ON DELETE RESTRICT VS ON DELETE CASCADE

On 03/08/2015 02:28 PM, Morgan Fainberg wrote: On March 8, 2015 at 11:24:37 AM, David Stanek (dsta...@dstanek.com ) wrote: On Sun, Mar 8, 2015 at 1:37 PM, Mike Bayer>wrote: can you elaborate on your reasoning that FK constraints should

Re: [openstack-dev] [Keystone]ON DELETE RESTRICT VS ON DELETE CASCADE

Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Keystone]ON DELETE RESTRICT VS ON DELETE CASCADE On March 8, 2015 at 11:24:37 AM, David Stanek (dsta...@dstanek.com) wrote: On Sun, Mar 8, 2015 at 1:37 PM, Mike Bayer wrote: can you elaborate on your reasoning that FK

Re: [openstack-dev] [Keystone]ON DELETE RESTRICT VS ON DELETE CASCADE

On March 8, 2015 at 11:24:37 AM, David Stanek (dsta...@dstanek.com) wrote: On Sun, Mar 8, 2015 at 1:37 PM, Mike Bayer  wrote: can you elaborate on your reasoning that FK constraints should be used less overall?  or do you just mean that the client side should be mirroring the same rules that would

Re: [openstack-dev] [Keystone]ON DELETE RESTRICT VS ON DELETE CASCADE

On Sun, Mar 8, 2015 at 1:37 PM, Mike Bayer wrote: > can you elaborate on your reasoning that FK constraints should be used less > overall? or do you just mean that the client side should be mirroring the > same > rules that would be enforced by the FKs? > I don't think he means that we will use

Re: [openstack-dev] [Keystone]ON DELETE RESTRICT VS ON DELETE CASCADE

Morgan Fainberg wrote: > 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. can you elaborate on your reasoning that FK constraints should be used less

Re: [openstack-dev] [Keystone]ON DELETE RESTRICT VS ON DELETE CASCADE

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 t

[openstack-dev] [Keystone]ON DELETE RESTRICT VS ON DELETE CASCADE

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 DEL