Adam Young ayo...@redhat.com 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
Adam Young ayo...@redhat.com 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.
Clint Byrum cl...@fewbar.com 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
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
Mike Bayer mba...@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:
On 03/08/2015 02:28 PM, Morgan Fainberg wrote:
On March 8, 2015 at 11:24:37 AM, David Stanek (dsta...@dstanek.com
mailto:dsta...@dstanek.com) wrote:
On Sun, Mar 8, 2015 at 1:37 PM, Mike Bayermba...@redhat.com
mailto:mba...@redhat.comwrote:
can you elaborate on your reasoning that FK
Clint Byrum cl...@fewbar.com 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 mba...@redhat.com wrote:
can you elaborate on your reasoning that FK constraints should be used less
overall? or do you just mean that the
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 mba...@redhat.com 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
On Sun, Mar 8, 2015 at 10:28 PM, Chen, Wei D wei.d.c...@intel.com 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
(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 mba...@redhat.com wrote:
can you elaborate on your reasoning
; 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, Mike Bayer mba...@redhat.com wrote
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
javascript:;) wrote:
On Sun, Mar 8, 2015 at 1:37 PM, Mike Bayer mba...@redhat.com
javascript
Excerpts from Mike Bayer's message of 2015-03-09 10:26:37 -0700:
Clint Byrum cl...@fewbar.com 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 mba...@redhat.com wrote:
can you elaborate on your reasoning that FK
Clint Byrum cl...@fewbar.com 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
Excerpts from Mike Bayer's message of 2015-03-09 17:26:36 -0700:
Clint Byrum cl...@fewbar.com 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
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
On Sun, Mar 8, 2015 at 1:37 PM, Mike Bayer mba...@redhat.com 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
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 mba...@redhat.com 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
Morgan Fainberg morgan.fainb...@gmail.com 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
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 mba...@redhat.com wrote:
can you elaborate on your reasoning
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
21 matches
Mail list logo