On Fri, 2009-01-16 at 00:38 +0100, Sebastian Bauer wrote: > I think ORM supposed to have save insert and update: > > save(force_insert=False,force_update=False) > update() == save(force_update=True) > insert() == save(force_insert=True)
There was a long discussion a couple of years ago about whether to add method names like that or not. In the end, it was my decision and I decided not to. There were reasonable arguments in favour of both alternatives, but the decisive issue for me is that since "insert" and "update" are both common words, introducing new methods with those names in the model method namespace had a reasonable chance of colliding with existing methods that people may have on their models (which would hide the Django versions). I, for one, don't like introducing even small backwards incompatibilities, particularly ones that would fail effectively silently, when we don't have to, and that was a guiding consideration in the API design even prior to Django 1.0. Even now, although adding these methods wouldn't strictly break our policy, it does run the risk of name collision with methods people have on their own models. Adding new names to the heavily used namespace (every single Model subclass uses that namespace) of Model should be done with extreme caution. > in that situation we could have clean code and we know that update is > realy update on DB Just like we already know that force_update=True means "force an update". You have to really try hard to misinterpret a save() call that uses that parameter. It's as explicit as can be. "Clean" isn't a unique condition: some piece of code can appear cleaner to one person than another piece, but it doesn't mean the latter is unclean. It just means you have a preference. The distinction is important. > i now we can have save(force_update=True) but update() looks better > and we have insert() already No, Model.insert() doesn't exist already. Whether you prefer update() to save(force_update=True) is stylistic and opinions will vary. As noted above, there is the namespace pollution issue to consider and that is the reason we don't have it. There's no harm done by omitting it. As noted, if you want it on your models, add it as part of a standard base class. You'll be happy and other people's code still won't break in mysterious ways. > IMHO save() is only wrapper for save_base() You've misunderstood things, in that case. Have a look at the method signatures. The save() provides the public API, whereas save_base() is the more internal API (and is something we can add parameters to, if required, without breaking the API stability guarantee). 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
