On Wed, Jul 28, 2010 at 12:02 PM, Jacob Kaplan-Moss <ja...@jacobian.org> wrote: > Hi Dennis -- > > I'm not totally thrilled with this proposal, though perhaps there's > some points I just don't get. As it is, though, I'm -0 on the idea. > update() is supposed to be an optimization that's "close to the metal" > of the database; adding potentially-hidden slow code to the mix rubs > me the wrong way. > > In general, signals are a very dangerous thing: they make side-effects > non-obvious, and make it hard to discover what's going to be called > when. They also add a not-insignificant overhead. I'm of the opinion > that they should be avoided except where critically important, and I > don't see this to be one of those cases. > > On Wed, Jun 16, 2010 at 7:38 AM, Dennis Kaarsemaker > <den...@kaarsemaker.net> wrote: >> However, I'd like to have a bit more control over what update() does, >> e.g. for auditing purposes. I know that I can simply write a few lines >> of code near every update() call to do what I want, but that violates >> DRY. > > I think you may have missed a few possibilities in your search for a > DRY solution to the problem. If I was trying to add some audibility > around QuerySet.update() I would: > > 1. Define a QuerySet subclass that extended update() to provide > whatever hooks I needed (this could be a signal, perhaps, or just the > code). > > 2. Make a Manager subclass that returned by QuerySet object from > get_query_set(). > > 3. Use said Manager (or a subclass) on each model that I want the behavior on. > > This gives me control over *where* my added behavior happens, and it's > completely clear to anyone reading the code that I've got a custom > Manager; they can follow the trail to the update behavior.
A bit of a seque, but I think this is a useful way to DRY this common need: http://djangosnippets.org/snippets/2117/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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.
