On Fri, 2007-06-01 at 09:25 -0700, Ben Schwarze wrote:
>
>
> On Jun 1, 4:19 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
> wrote:
> > On Fri, 2007-06-01 at 10:07 -0400, Benjamin Slavin wrote:
> > > On 6/1/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> > > > You can't tell if it's an update wi
On Jun 1, 4:19 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Fri, 2007-06-01 at 10:07 -0400, Benjamin Slavin wrote:
> > On 6/1/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> > > You can't tell if it's an update without asking the database sometimes
> > > (if the primary key value i
On 6/1/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> You're proposal (doing a database check and moving the "pre_save"
> dispatch lower) has introduced an extra database query for every single
> save, whether it's needed or not
Two points here...
First, there's already a database check for
On 6/1/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> Let's ask the different question: what's the use case for a pre_create
> signal that isn't already possible with pre_save?
In my case it's a matter of enforcing privileges. Highly granular
pirvileges can include "create" among other thin
On Sat, 2007-06-02 at 00:19 +1000, Malcolm Tredinnick wrote:
> On Fri, 2007-06-01 at 10:07 -0400, Benjamin Slavin wrote:
> > On 6/1/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> > > You can't tell if it's an update without asking the database sometimes
> > > (if the primary key value is not
On Fri, 2007-06-01 at 10:07 -0400, Benjamin Slavin wrote:
> On 6/1/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> > You can't tell if it's an update without asking the database sometimes
> > (if the primary key value is not None). So pre_save can't make it
> > available unless the semantics o
On 6/1/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> You can't tell if it's an update without asking the database sometimes
> (if the primary key value is not None). So pre_save can't make it
> available unless the semantics of "pre_save" change so that it's no
> longer prior to anything in
On Fri, 2007-06-01 at 09:40 -0400, Benjamin Slavin wrote:
> On 5/31/07, Ben Schwarze <[EMAIL PROTECTED]> wrote:
> > What about a simple additional attribute that wil be. This could be
> > fetched in listener functions (e.g. is_update=True/False)?
> > [...]
> > Any ideas about that?
>
> I like thi
On 5/31/07, Ben Schwarze <[EMAIL PROTECTED]> wrote:
> What about a simple additional attribute that wil be. This could be
> fetched in listener functions (e.g. is_update=True/False)?
> [...]
> Any ideas about that?
I like this idea... and it shouldn't pose any problem with backwards
compatibility
On 6/1/07, Amit Upadhyay <[EMAIL PROTECTED]> wrote:
> How about doing a:
>
> self.is_new = not bool(self.id)
>
> in pre_save and
>
> if self.is_new: # do something
>
> in post_save?
Unfortunately, that won't work in the case of OneToOne models. They
are required to have their primary key value
n 5/31/07, Ben Schwarze <[EMAIL PROTECTED]> wrote:
>
>
> I've reconsidered the post_create signal issue, and can imagine that
> the pre_save and post_save signals may be extended. What about a
> simple additional attribute that wil be send. This could be fetched in
> listener functions (e.g. is_upd
I've reconsidered the post_create signal issue, and can imagine that
the pre_save and post_save signals may be extended. What about a
simple additional attribute that wil be send. This could be fetched in
listener functions (e.g. is_update=True/False)?
I'm not that sure whether it would be an bac
Benjamin Slavin wrote:
> On 5/30/07, Robert Coup <[EMAIL PROTECTED]> wrote:
>
>> So the post_create signal would be triggered *after* the transaction was
>> committed? The patch in 2154 certainly doesn't handle that case.
>>
>
> That's not what I was trying to communicate. It was mentione
On 5/30/07, Robert Coup <[EMAIL PROTECTED]> wrote:
> So the post_create signal would be triggered *after* the transaction was
> committed? The patch in 2154 certainly doesn't handle that case.
That's not what I was trying to communicate. It was mentioned that
you won't know if "the save is succe
Benjamin Slavin wrote:
> Forest already mentioned not knowing if the object persistence will be
> successful.
Fair enough :)
> In many cases using transactions will rollback any
> changes that happen if a problem pops-up later (assuming those changes
> are in the database).
>
So the post_crea
On 5/30/07, Robert Coup <[EMAIL PROTECTED]> wrote:
> Why not connect to pre_save and check whether the primary key is None,
> similar to the accepted way to check for creation if you override
> Model.save()?
Forest already mentioned not knowing if the object persistence will be
successful. In ma
On Thu, May 31, 2007 at 09:16:07AM +1200, Robert Coup wrote:
> Ben Schwarze wrote:
> > Due to this process, I was looking for a way fetch a signal after the
> > creation of an object.
> > Currently Django has the pre_save and post_save signals that will be
> > send before and after saving the objec
Ben Schwarze wrote:
> Due to this process, I was looking for a way fetch a signal after the
> creation of an object.
> Currently Django has the pre_save and post_save signals that will be
> send before and after saving the object. But there seems to be no way
> to determine whether an object has b
Hi all,
I was thinking about using signals in one of my applications and tried
to figure out which Django signals are sufficient for my purposes and
where I may need some extended functionality.
Due to this process, I was looking for a way fetch a signal after the
creation of an object.
Currentl
19 matches
Mail list logo
