-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
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
-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
"""
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
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_
"""
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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'
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
26 matches
Mail list logo