On Tue, Mar 23, 2010 at 11:04 PM, jrs <j...@framemedia.com> wrote: > Thanks Russ > > On Mar 23, 10:33 am, Russell Keith-Magee <freakboy3...@gmail.com> > wrote: >> On Tue, Mar 23, 2010 at 10:21 PM, jrs <j...@framemedia.com> wrote: >> >> > On Mar 23, 10:05 am, "ge...@aquarianhouse.com" >> > <ge...@aquarianhouse.com> wrote: >> >> Filter would be better :) >> >> >> Container.objects.filter( >> >> pk=container_id >> >> ).delete() >> > > Reasons I see that makes get() a better option- > > 1) There will always be one record returned as it's a join on a > primary key > 2) For reasons unknown to me, the overridden model delete method is > not fired for a filter, instead the 581 queries are executed.
Because, again, as documented [1], a queryset delete is treated as a "bulk delete", and delete() is not invoked on each of the deleted objects in the queryset. [1] http://docs.djangoproject.com/en/dev/topics/db/queries/#deleting-objects > The recommendation to avoid web requests for long-chain deletes, most > of the time, makes no sense. There are frequently valid cases of long- > chain deletes being basic to web requests. It makes perfect sense. Regardless of whether you're using Django or not, it is incumbent on a developer to think about the consequences of the actions they allow to be invoked via a HTTP request. If you're going to maintain referential integrity, you have to follow the delete cascade. If you know your object hierarchy is complex, you also know this cascading will take time under some circumstances. Therefore, you need to design your application so that this isn't a problem. The fact that there are legitimate use cases for deleting objects doesn't mean that the deletion needs to happen in the view, or that deletion needs to happen at all. For example, you could: * Build an object hierarchy that doesn't lead to huge cascades * Mark the object as hidden, rather than deleting the object * Defer the deletion to a work queue and so on. The only alternative is to abandon referential integrity. You can go down this path if you want, but you will end up spending all your time protecting against errors that are raised because an object you thought was there actually isn't. You can pursue this direction if you want, but Caveat Emptor. Ultimately, defending against cascading deletes is no different to defending your application against slow SELECT queries. It's easy to write a SELECT query that requires lots of joins that will take a long time to execute. It's up to the developer to make sure these queries aren't executed as the result of visiting a view. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
