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 of "pre_save" change so that it's no > > longer prior to anything in save() happening. > > I agree that this would push the pre_save call further down into the > internals of save()... I don't know that there's anything wrong with > that, aside from having two lines of code to dispatch the pre_save > signal (with different is_update values).
Let's ask the different question: what's the use case for a pre_create signal that isn't already possible with pre_save? > One of the possibilities that had come up in an off-list discussion > with a colleague was to change the semantics of model instantiation to > mark new objects as _is_new (or some such thing). Once an object is > saved or is retrieved from the database it would be marked as not new. > (This falls apart if people manually change the PK value, but I don't > know how likely that is.) The last sentence is exactly the problem. You still have to do the INSERT vs. UPDATE check and there are still the problems with validators and custom primary keys. Might be other problems, too. I can cheat a little here, because I've been thinking through some similar problems whilst working on validation and custom primary keys: I think it works if you have a tri-state variable, instead of a boolean. The states are "known to be new" -- which is basically primary key is None, "known to be old" -- which is set when retrieved from database and primary key is not changed, and "unknown" -- which is, well, hopefully self-explanatory. I haven't done any profiling of this over the current system, though. It saves time slightly in the saving of an existing object case. Needs testing to know how much, though. The argument in favour of a change like that is that it's probably fairly easy (fairly easy, not trivial. Because accesses can be done through the field name or the "pk" alias and related fields as primary keys, some care is required). Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
