On 28/11/11 18:28, Paul Winkler wrote:
> There was an old thread about this at
> https://groups.google.com/group/django-developers/browse_frm/thread/6e41ee7b08d50710/9cf6375d97bed499?lnk=gst&q=update+signal#9cf6375d97bed499
> which fizzled out last summer with no conclusion.
> (I'd reply to that thread but google groups apparently won't let me
> reply to something that old.)
>
> The ticket is at https://code.djangoproject.com/ticket/13021
>
> I want this feature for much the same reason as Dennis: while there
> were suggestions in the old thread about ways to avoid DRY in code
> that is fully under your control, there has "not yet [been] a
> suggestion that integrates with third party applications without
> modifying them". A new signal would provide a clean, easy way to do
> that - and would be easily understood and documented since it would
> fit the existing pattern of pre_save, pre_delete, etc.
>
> If this is going to be "wontfix", it'd be great to at least see that
> finalized on the ticket, and maybe a note in the docs that
> QuerySet.update() doesn't send any signals.
Sorry, I didn't see this message before I closed the ticket. I think the
reason Jacob gave still stands - that 'update' is meant to be closer to
SQL, and something you can rely on not to have performance side effects.
Having seen a lot of code recently with horrible performance due to
developers using post_save signals instead of adding the change in the
right place, I'm glad that update() is something I can rely to avoid
that mess.
(For example, they had a post_save signal on a model that did expensive
image processing of uploaded images. What they should have done was
override ModelAdmin.save() to call this image processing, since that was
the only place where the models image data could change, and there were
many other places that called save() on the model where there was no
possibility of the image files being changed).
I think if you need to add custom behaviour to an update() call in a
third party app, that app should provide an appropriate hook for it (in
a similar way to how the ModelAdmin allows you to override save() to
apply custom behaviour). Providing a generic hook for all update() calls
would be an anti-feature IMO.
The docs for QuerySet.update() already say that no post_save/pre_save
signals are emitted. Do we really need to add that no other signals are
emitted, when there aren't others that you would expect to be emitted?
Regards,
Luke
--
Noise proves nothing. Often a hen who has merely laid an egg
cackles as if she laid an asteroid.
-- Mark Twain
Luke Plant || http://lukeplant.me.uk/
--
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.
