The options for save() API seem to be: 1. refresh_fields=[...] for save() - if set, then issue RETURNING for fields mentioned in the refresh_fields API. 2. expressions: my_model.updated_at = TransactionNow(); my_model.save(), where TransactionNow is flagged to refresh the value from DB post-save. 3. field flags like done in the PR.
Field flags are nice for things you always want to load from database (say, updated_at). If the use cases we target are "generate value in db on insert" and "generate value in db on insert or update", and only those, then I think we can go with just a flag that tells Django to always skip the model's value on save(), and to reload from DB always. We are going to override the assigned value on save(), but I think it has to be this way. Consider: a_object.save() # a_object.updated_at is set to '2016-02-03' as it is database delegated a_object.save() # a_object.updated_at has a value, so we should error if we don't ignore the value forcing users to set the value to None pre-save breaks the whole field flag feature. We could go directly with expressions in that case. We could also use the value in the update and require the DB trigger to ignore the value. We don't have a separate flag for doing the refresh on insert only, but that isn't IMO such a big problem. We are going to add a minor overhead to updating by refreshing a field value from the DB when it hasn't changed, but making the API simpler is worth this IMO. So, my opinion is that for the field flags API we need just one flag. A name like db_generated comes to mind. This gives a nice way to support the most common use case - that of calculating an inserted_at/updated_at field directly in DB. After we have the field flag API, I think we should aim for expressions support. For expressions we should have enough flags for allowing full control over save() behavior. So, if the db_generated field flag isn't enough for some use case, you can go low-level and use expressions directly. We could perhaps even allow db_generated value to be an expression - if so, that expression would be used on save() and bulk_create(). For the update_fields change, I think we can do that completely separately. The same goes for changing the way how deferred fields are implemented. - Anssi -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/dedc791d-232d-4c93-9716-687963ca5272%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
