On Apr 9, 5:04 am, Russell Keith-Magee <freakboy3...@gmail.com> wrote: > On Thu, Apr 9, 2009 at 5:02 AM, Jeremy Dunck <jdu...@gmail.com> wrote: > > > On Tue, Mar 31, 2009 at 5:47 PM, Malcolm Tredinnick > > <malc...@pointy-stick.com> wrote: > > >> On Tue, 2009-03-31 at 14:48 -0500, Jeremy Dunck wrote: > > ... > >>> I'm aware of ticket #7539, but would prefer to keep the scope narrower > >>> and ask the hopefully-useful question-- is #9308 a bug? If so, I'd > >>> like to close it for 1.1. > > >>> In summary, #9308 describes a situation where B has a nullable FK to > >>> A, and an instance of A is being deleted. Currently, any B's related > >>> to A also get deleted. > > ... > >> In the case of #9308, specifically, I think setting the related pointers > >> to NULL would be a better solution, but I'm not sure if it's considered > >> a fundamental change in behaviour, inconsistent with what we're doing > >> now. > > > Would any other committers chime in here? Is #9308 a bug? > > Apologies - I had this marked as something to respond to, but it got > buried in some other mail. > > I can see at least 2 readings of #9038. Consider the following setup > (much the same as the ticket describes): > > class F(Model): > ... > > class E(Model): > fk = ForeignKey(F, null=True) > > f1 = F().save() > e1 = E(fk=f1).save() > > What does f1.delete() do at this point: > > Current behaviour > 1. Transaction is started > 2. f1 is deleted > 3. e1 is deleted > 4. Transaction is closed. > > This relies upon deferrable constraint checking, as the deletion of f1 > makes e1 a temporarily inconsistent object. > > The ticket description seems to imply that this is a bad thing to do, > but I can't see why - this is exactly what deferred checks are for. > The ticket suggests that the problem is with MSSQL not implementing > deferred constraints - in which case, the problem lies with MSSQL, not > with Django. > > There is a secondary case, which is raised by #7778 (which was closed > as a dupe of #9308) - dealing with legacy databases that haven't got > foreign keys defined as DEFERRABLE. > > Reading 1: > 1. Transaction is started > 2. e1.fk is set to NULL > 3. f1 is deleted > 4. e1 is deleted > 5. Transaction is closed. > > I can't say this suggestion impresses me. If your database doesn't > implement deferred constraint checking properly, you have much bigger > problems to deal with. Here's a nickel - go buy yourself a real > database. > > The 'legacy database' problem is a slightly more compelling reason to > fix the problem, but I'm still not convinced it's a problem that we > want to tackle. Malcolm commented on #7778 that this wasn't > necessarily a class of problem that we want to address, and I tend to > agree. Django guarantees that it works with tables that are created > the way Django expects them to be created. Django may also work with > legacy tables, but I view this as a convenience, not part of our > design contract. If you have a foreign key that isn't set up the way > Django expects, then I would expect to see problems. > > Reading 2: > 1. Transaction is started > 2. e1.fk is set to NULL > 3. f1 is deleted > 4. Transaction is closed. > > This is the backwards incompatible interpretation, changing the > behavior of bulk deletion from an emulation of ON DELETE CASCADE to an > emulation of ON DELETE SET NULL. This is essentially #7539-lite. > > As appealing as this change may be, unfortunately, I don't think we > have much wiggle room. The documentation for delete() [1] says > outright that qs.delete() == ON CASCADE DELETE, and that's what the > current implementation does. Regardless of the merits of any other > approach, that is both the documented and implemented interface as of > Django v1.0. Backwards incompatibility sets the rules on this > occasion. > > [1]http://docs.djangoproject.com/en/dev/topics/db/queries/#deleting-objects > > However, I can see the appeal of having better controls over deletion > behavior. IMHO, there is a lot more we could be doing to (1) expose > other deletion cascade strategies, and (2) use DB native > implementations rather than python implementations of deletion where > they are available. This is the goal of #7539, but it's not going to > be a simple change. > > In summary - for me #9308 isn't a wontfix ticket; by reading 1, it's a > pointless change; by reading 2, it's a backwards incompatible change.
doesn't all this backward compatibility and nullables and deletions of related objects get solved by something mentioned in http://code.djangoproject.com/ticket/8168 (i know it's yet another signal) but it would seem to allow way more flexibility in the deletion propagation issue(s). especially for FKs in models that rely on apps outside the current App (where an overloaded "delete" method is sometimes not possible to be used) bo --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
