On Wed, Jul 28, 2010 at 9:37 AM, Dennis Kaarsemaker
<den...@kaarsemaker.net>wrote:
> Is nobody interested?
>
> I'm using this in production for auditing purposes and works just fine.
> If only it were built in, then I wouldn't have to monkeypatch :)
>
> I've rebased it to trunk again and it still works.
>
> On wo, 2010-06-16 at 14:38 +0200, Dennis Kaarsemaker wrote:
> > I know that queryset.update does not call .save() for each instance and
> > I know why. I even agree with it :)
> >
> > 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.
> >
>
>From what I've seen, you're probably going to encounter some resistance to
any proposal that includes adding new signals to the core, especially if
they are never going to be used by the vast majority of developers, and
especially if there is any workaround possible.
In this specific case, is this not a problem that can be solved by a custom
manager on the specific models that need this functionality? That way you
don't RY so much:
class ControlledUpdateManager(django.db.models.Manager):
def update(self, *args, **kwargs):
# pre-update code
super(ControlledUpdateManager,self).update(*args, **kwargs)
# post-update code
class MyModel(django.db.models.Model):
...
objects = ControlledUpdateManager()
You can apply that manager to any models that need the same pre- and post-
update code, or subclass from it, or use it as a mixin as necessary.
--
Regards,
Ian Clelland
<clell...@gmail.com>
--
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.
