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 every save that contains a
primary key... so this wouldn't change that.
Second, it isn't necessary to do this for every save, only updates as
is currently done. (very quick pseudo code follows)
if pk_set:
do_query (as is already done)
if found:
send pre_save with is_update=True
if not pk_set or not record_exists:
send pre_save with is_update=False
> and also a small race condition -- just
> because it's not in the database yet, doesn't mean it won't be when you
> are using that information.
No argument there.
Technically there's already a small race condition, so what's the big
deal with making the window bigger? ;-) Seriously though, you're
completely right, and it's a possible problem.
> So, I would prefer that if you need this
> information desperately before the save method, it's better to do it as
> part of the pre_save call and handle the database interaction yourself
> when you can use appropriate transactioning (which may or may not be
> available through Django at the moment) to ensure that your
> pre-condition remains true, if necessary.
In my case I'm willing to deal with the race condition, but I
understand your concern.
- Ben
--~--~---------~--~----~------------~-------~--~----~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
