David Larlet wrote:
> Le 28 avr. 08 à 09:33, David Danier a écrit :
>
>
>>> Sometimes when calling save(), we know (for business reasons) that it
>>> must create a new object or raise an error. Similarly, in other
>>> cases,
>>> it either must update an existing object or raise an error.
>>>
>> I think discussion about this issue has been on this list before, last
>> time someone suggested adding create() and update()...and keeping
>> save()
>> as an method calling these two, like:
>> ---------8<----------------------------------------------------
>> class Model(...):
>> def save(self, ...):
>> if self.has_pk() and self.pk_exists():
>> self.update()
>> else:
>> self.create()
>> def update(): ...
>> def create(): ...
>> ---------------------------------------------------->8---------
>>
>> So what is the big advantage of having an new parameter in save() like
>> you suggested? With having create()/update() you can do similar
>> things.
>>
>> Additionally it would be possible to override only parts of the
>> save()-logic in classes extending Model (for example when needing to
>> calculate field-values on create, but not on insert...which is
>> currently
>> difficult).
>>
>> And, of course, you would have no problems with naming the new
>> parameter
>> and difficulties in creating self-explaining possible values ("not
>> must_create", rather than "must_not_create").
>>
>
> I'm +1 on this solution, which turns the well known pattern:
>
> def save(self):
> if not self.id:
> self.some_date = datetime.now()
> super(Model, self).save()
>
> to:
>
> def create(self):
> self.some_date = datetime.now()
> super(Model, self).create()
>
> BTW, create()/update() sounds more explicit to me than save().
>
You could argue that the separate-method solution has better cohesion.
Malcolm's point that this is very much a minority use-case, and that
mostly the two methods will anyway simply call a modified save with
alternative values of the flag (whose names are a little smelly, by the
way) is reasonable, I suppose.
But it does seem to me that create() and update() are more explicit than
save(must_create=True) and/or save(must_update=True). The separate
method solution also removes the possibility of the illegal fourth case
(must_update==must_create==True), which means there would be no need to
test for it.
In summary, we are arguing around the ragged edges of an overall very
neat system.
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
