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. Yours, Russ Magee %-) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
