Hey! I have also been thinking to the problem lately.
If you're doing it because it's related to your business logic for a specific model, I would rather see this feature in the model definition. Why could you not include a parameter in the Meta class, like no_update = True ? By default, this parameter would be False. We you call save(), the Model checks the value of no_update, and creates a new entry if it's set to True instead of updating the current entry. I see some advantages to this approach: - you will never forget to add the parameter when calling the save() method. - the property is written once in the code, so you don't repeat yourself - it is easier to manage it for the admin interface: if it calls save(), it will create a new record transparently Btw, thank you very much for your work on queryset-refactor :) Regards, -- Grégoire Cachet Le 27 avr. 08 à 19:53, Malcolm Tredinnick a écrit : > > One of the minor cleanup items I've got on my list now that the query > stuff is mostly done is fixing model saving so that in the odd cases > where finer control is necessary, we have it. > > 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. > > For example: creating a new employee in the a business system. The > primary key is their tax file number (unique per person). After > entering > all the details, we hit save. This *must* create a new entry. If there > is an existing entry with the same tax file number, it's an error. > Under > no circumstances should the existing entry be updated. > > Conversely, we're now giving this person a raise. We enter the new > salary and the tax file number and hit save. It must update an > existing > record. If a record with that primary key doesn't exist, it's an error > and no new record should be created. > > These situations don't arise all the time, but in some situations they > can be fairly frequent and when you need them, it's important. > > There are at least three possibilities for the API here. In all cases > the default behaviour is as it is now. > > (1) Model.save(must_create=None) where "must_create" is True (must > create), False (must not create) or None (try an update; if that > fails, > insert). > > Pros: one parameter only (shorter; easier to subclass). Uses > existing, builtin constant values. > > Cons: "False" tends to read most naturally as "not > must_create", > rather than "must_not_create", so it does slightly fail the > reading test. > > (2) Model.save(method=DEFAULT) and this time "method" takes one of > three > constant values (making up the names a bit): "DEFAULT", "MUST_CREATE", > "MUST_UPDATE". > > Pros: very clear what's going on when you use something other > than DEFAULT. > > Cons: now you have to import the constant you want to use. > Alternatively, we put the constant on the Model class and now > you have to write Model.MUST_CREATE, which divides opinions a > bit as to readability (not everybody likes model-level > constants, so they're not used to reading them). > > (3) Model.save(must_create=False, must_update=False). > > Pros: Uses existing builtins. > > Cons: Two binary parameters means four possibilities. The > (True, > True) case is invalid. It's also two things you have to specify > when subclassing save(). > > > If it was just me, I'd use (1). But I'm not typical. For our audience, > I'd probably favour (2) and make the constants have string values of > "create" and "update" so you could use them in literal form and > they're > still readable -- a kind of halfway alternative to having to import > the > constants if you don't want to. > > Thoughts? > > (The implementation of all this is pretty much trivial. Getting the > API > right is the hard bit here.) > > Regards, > Malcolm > > -- > For every action there is an equal and opposite criticism. > 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 -~----------~----~----~----~------~----~------~--~---
