Re: Allowing models to influence QuerySet.update

2011-11-30 Thread Carl Meyer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/29/2011 11:32 PM, Anssi Kääriäinen wrote: > I should not have said that this would be a good optimization, and > used the possible optimizations wording. I haven't got any performance > problems when using delete in 1.3. So from my point > of vie

Re: Allowing models to influence QuerySet.update

2011-11-29 Thread Anssi Kääriäinen
On Nov 30, 12:31 am, Carl Meyer wrote: > > Now, this is not that inefficient - but it would be a good > > optimization to NOT fetch the instances if there are no listeners for > > pre/post delete signals and there are no cascades (or all cascades are > > DO_NOTHING). Even if there are cascades, yo

Re: Allowing models to influence QuerySet.update

2011-11-29 Thread Carl Meyer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/29/2011 02:58 PM, Kääriäinen Anssi wrote: > """ > H, that is not ideal behavior. You mean QuerySet.delete() calls > the signal for each deleted object, rather than doing a delete at the > database level? > """ These two things aren't mutuall

RE: Allowing models to influence QuerySet.update

2011-11-29 Thread Kääriäinen Anssi
""" H, that is not ideal behavior. You mean QuerySet.delete() calls the signal for each deleted object, rather than doing a delete at the database level? """ This might not be exactly accurate, but I think it goes something like this: - Fetch all the to-be deleted objects (one query) - Che

Re: Allowing models to influence QuerySet.update

2011-11-29 Thread Adrian Holovaty
On Tue, Nov 29, 2011 at 3:27 PM, Kääriäinen Anssi wrote: > Is this correct for delete? A quick test (A1 is a model which I have hanging > around - details about it aren't important): > > from django.db.models.signals import post_delete > > def foo(*args, **kwargs): >    print args, kwargs > post_

RE: Allowing models to influence QuerySet.update

2011-11-29 Thread Kääriäinen Anssi
""" I also noticed in db optimization docs that we have explicitly documented update() and delete() as bypassing signals, and I think we should honour that. https://docs.djangoproject.com/en/dev/topics/db/optimization/#use-queryset-update-and-delete """ Is this correct for delete? A quick test (A

Re: Allowing models to influence QuerySet.update

2011-11-29 Thread Paul Winkler
On Nov 29, 1:17 pm, Luke Plant wrote: > On 29/11/11 17:10, Paul Winkler wrote: > > > Hmm. I've been thinking of signals as key plug points for third-party > > apps, as well as a way to avoid needing database-specific stored > > procedures and triggers. Maybe I need to rethink that. > > Signals cou

Re: Allowing models to influence QuerySet.update

2011-11-29 Thread Luke Plant
On 29/11/11 17:10, Paul Winkler wrote: > Hmm. I've been thinking of signals as key plug points for third-party > apps, as well as a way to avoid needing database-specific stored > procedures and triggers. Maybe I need to rethink that. Signals could be used for your use case, as an alternative to

Re: Allowing models to influence QuerySet.update

2011-11-29 Thread Paul Winkler
On Nov 29, 7:25 am, Luke Plant wrote: > The docs for QuerySet.update() already say that no post_save/pre_save > signals are emitted. Mea culpa, somehow I missed that. Thanks for pointing it out, and updating the ticket. Hmm. I've been thinking of signals as key plug points for third-party apps,

Re: Allowing models to influence QuerySet.update

2011-11-29 Thread Luke Plant
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 th

Allowing models to influence QuerySet.update

2011-11-28 Thread Paul Winkler
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

Re: Allowing models to influence QuerySet.update

2010-07-28 Thread Jeremy Dunck
On Wed, Jul 28, 2010 at 2:46 PM, Jeremy Dunck wrote: ... > A bit of a seque, but I think this is a useful way to DRY this common need: > http://djangosnippets.org/snippets/2117/ segue, but non sequitur is what I meant in any case. :-) -- You received this message because you are subscribed to

Re: Allowing models to influence QuerySet.update

2010-07-28 Thread Jeremy Dunck
On Wed, Jul 28, 2010 at 12:02 PM, Jacob Kaplan-Moss 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

Re: Allowing models to influence QuerySet.update

2010-07-28 Thread Dennis Kaarsemaker
On wo, 2010-07-28 at 14:20 -0500, Jacob Kaplan-Moss wrote: > On Wed, Jul 28, 2010 at 2:08 PM, Dennis Kaarsemaker > wrote: > > As implemented in my github branch it is called once (well, twice, pre > > and post) per update() statement, not once per object. > > Okay, I missed that -- sorry. > > Do

Re: Allowing models to influence QuerySet.update

2010-07-28 Thread Jacob Kaplan-Moss
On Wed, Jul 28, 2010 at 2:08 PM, Dennis Kaarsemaker wrote: > As implemented in my github branch it is called once (well, twice, pre > and post) per update() statement, not once per object. Okay, I missed that -- sorry. Doesn't really change how I feel about the feature, though: I don't see the p

Re: Allowing models to influence QuerySet.update

2010-07-28 Thread Dennis Kaarsemaker
On wo, 2010-07-28 at 13:43 -0500, Jacob Kaplan-Moss wrote: > On Wed, Jul 28, 2010 at 12:53 PM, Dennis Kaarsemaker > wrote: > > This would add boilerplate to each class and makes it nontrivial to do > > update() tracking for third party applications. I don't see why pre/post > > update signals are

Re: Allowing models to influence QuerySet.update

2010-07-28 Thread Jacob Kaplan-Moss
On Wed, Jul 28, 2010 at 12:53 PM, Dennis Kaarsemaker wrote: > This would add boilerplate to each class and makes it nontrivial to do > update() tracking for third party applications. I don't see why pre/post > update signals are worse than pre/post save and delete. Because the save/delete signals

Re: Allowing models to influence QuerySet.update

2010-07-28 Thread Dennis Kaarsemaker
On wo, 2010-07-28 at 12:02 -0500, Jacob Kaplan-Moss 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

Re: Allowing models to influence QuerySet.update

2010-07-28 Thread Ian Clelland
On Wed, Jul 28, 2010 at 9:37 AM, Dennis Kaarsemaker 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-0

Re: Allowing models to influence QuerySet.update

2010-07-28 Thread Jacob Kaplan-Moss
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 wr

Re: Allowing models to influence QuerySet.update

2010-07-28 Thread Dennis Kaarsemaker
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.upd

Allowing models to influence QuerySet.update

2010-06-16 Thread Dennis Kaarsemaker
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 wan

Re: Allowing models to influence QuerySet.update

2010-03-07 Thread Dennis Kaarsemaker
On ma, 2010-03-08 at 08:09 +0800, Russell Keith-Magee wrote: > On Mon, Mar 8, 2010 at 7:56 AM, Dennis Kaarsemaker > wrote: > > I have now added tests and documentation. Comments are still welcome, I > > have not received any feedback yet :( > > Please don't take it personally -- it's just that we

Re: Allowing models to influence QuerySet.update

2010-03-07 Thread Russell Keith-Magee
On Mon, Mar 8, 2010 at 7:56 AM, Dennis Kaarsemaker wrote: > I have now added tests and documentation. Comments are still welcome, I > have not received any feedback yet :( Please don't take it personally -- it's just that we're just not really fielding new features at the moment. The attention of

Re: Allowing models to influence QuerySet.update

2010-03-07 Thread Dennis Kaarsemaker
I have now added tests and documentation. Comments are still welcome, I have not received any feedback yet :( On wo, 2010-03-03 at 19:00 +0100, 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'

Allowing models to influence QuerySet.update

2010-03-03 Thread Dennis Kaarsemaker
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 wan