> For this particular case it saves a whole line. One concern I have is
> that if there's more complex logic in your overridden save method, some
> of it is going to be useful in both cases and now you have to create
> extra sub-functions for the common bits and remember to call them both
> times. It leads to duplication. If you look around at sample code on
> django-users and other places, you can see people doing a number of
> pieces of auxilliary processing as a result of save happening on the
> instance, so this isn't a trivial issue.
No, it does not duplicate code, as you still could use save() for common
code.
>> BTW, create()/update() sounds more explicit to me than save().
>
> Which immediately leads to one of the problems with it. Suppose I'm
> writing a function that accepts objects, does something to them and then
> wants to save them. Do I call create() or update()? There's no way to
> tell. Currently, I call save() with no ambiguity problem.
>
> Also, this presents an unnecessary backwards-incompatibility. Every
> single piece of code now has to change to use one or other of these
> methods. Every save() call. Currently and with the parameter approach,
> *zero* existing code has to change initially. If you want to support the
> must insert vs. must update difference, you can add a parameter (or two,
> depending on which approach we take) and it's still backwards
> compatible.
Sorry, but this sounds like you did not read my email at all (to which
David Larlet sent a reply). I proposed still having save(), but
implementing it like this:
---------8<----------------------------------------------------
class Model(...):
def save(self, ...):
if self.has_pk() and self.pk_exists():
self.update()
else:
self.create()
def update(...): ...
def create(...): ...
---------------------------------------------------->8---------
I don't think this will break _any_ code using the old version of save().
> Finally, there's a namespacing problem. The current create() method,
> which is really just a shortcut for __init__() + save() lives on the
> model manager. An update() method (and presumably your version of
> create()) would live on the class instance. "Update" is a very common
> word and there are a number of non-database uses for it.
You don't have to stick to this names. I just used them, as I think they
are pretty self-explainig.
Greetings, David Danier
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
