I don't really like the idea of having extra options on save (mostly because I have a lot of save calls that already. Maybe I don't quite see the point. I proposed an internal flag a while back which would determine if something was actually being created or updated. I don't think it was accepted but it added _is_stored to models. This seems a lot cleaner and is more standard through DB implementations.
On Apr 28, 5:02 am, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Mon, 2008-04-28 at 13:49 +0200, David Danier wrote: > > > 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. > > Common stuff *must* to be called from both create() and update() in your > case because you're proposing that people should be allowed to call them > directly. > > That means save() is only ever going to be a placeholder for backwards > compatibility. Not worth it. > > > > > > > >> 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: > > I did read your mail. Then, whilst writing my reply, I forgot that you > had proposed this plan because I was noting the problem with the common > code. save() becomes a dead method here unless people are forced to call > it. If an individual wants to split their save() handling into a create > and an update path in separate functions, that's fine. They can do that. > But Django's core doesn't need to do that; there just isn't the amount > of code to require it. > > I didn't mean to dismiss your code fragment, David. I apologise. I was > trying to collapse multiple responses into one. > > [...] > > > You don't have to stick to this names. I just used them, as I think they > > are pretty self-explainig. > > The point is that any names have the potential for a clash. We're very > miserly about taking names form the common namespace for that reason: > you have to pick something easily understandable and not likely to > collide. Not introducing any new names is safest of all. > > Regards, > Malcolm > > -- > Save the whales. Collect the whole set.http://www.pointy-stick.com/blog/ --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
