Like it has been discussed a while ago [1] about adding *db_default*, we should stick with something similar to that and support updates as well.
My 2 cents here. I like the idea Anssi has proposed to delegate as much as possible using expressions. So I would propose similar to what discussed in the other thread using updated_at = DateTimeField(db_default=Expression, db_update=Expression) (I don't like the param name *db_update* but you got the idea). Updating existing records. I would opt for leaving out fields which have a db_update parameter, but still allow to override this behavior by specifying those fields explicitly instance.save(update_fields=...). And the same for MyModel.objects.filter().update(**fields) we should not include so called *auto fields* in the update statement but we should never leave out a field explicitly specified, (we already have problems how to change pk values on existing records, and we don't want more behavior like that). We should refresh values for records on insert and update using the RETURNING clause for those databases which support it. And defer fetching the new value for other databases and for update only, since for insert we already have to fetch the pk anyway, so we can fetch the other values as well. An interesting idea like Anssi proposed would be to allow refreshing values behavior be controlled via the Expression. For queryset methods like bulk_create and update we can already control deferring values for fields using *.defer()* and *.only()*. So if one would really want to save the extra overhead fetching new values from db after update, this can be done by MyModel.objects.get(pk=instance.pk).update(). I don't like Field(db_computed=True) it adds very minimal control over how and what that does. To sum up: 1) fields should have flags how they are used in insert / update queries. 2) controlling behavior should be done via Expressions 3) Field api should add 2 attributes *db_default* and *db_update* (perhaps some better param name) 4) Do not limit overriding save behavior on a per query bases. [1] https://groups.google.com/forum/#!msg/django-developers/3mcro17Gb40/NPINCcyyBAAJ On Feb 6, 2016 6:24 AM, "Owais Lone" <[email protected]> wrote: > Shai and Ayeric, thank you so much for the feedback. The PR did indeed > snowball into a much bigger one that I had initially planned. I agree with > all points except, > > > - controlling this behavior in the query rather than in the field > definition — this avoids the awkward “ignore what the field says” query > parameter > > The main reason this PR exists is to let the fields decide if they should > be updated/refreshed or not. If we don't define this behavior on the > fields, then the feature will never work with 3rd party apps as developers > will have to consciously remember to use some method on query API. For > example, we could add a pguuid field to postgresql package that sets > behaves like a normal uuid field but calculates the value using > postgresql's uuid function. This would only work if the we define the > preference on the field itself and the query API implicitly respects that. > > The minimum public API we would need to make this happen is to add an > option to the Field class, something like, > > > id = models.IntegerField(db_computed=True) > > `db_computed` would make django do 2 things, it would implicitly ignore > the field when updating and inserting and it would auto fetch the value > from the DB after every insert/update on supported backends. That's it. > Everything else was added to make this a bit flexible, like to make a field > behave like this only or INSERT or on UPDATE but I think even having just > one param that does it for both insert and update would be awesome! > > -- > Owais > > On Monday, February 1, 2016 at 2:03:26 PM UTC+5:30, Aymeric Augustin wrote: >> >> > On 31 janv. 2016, at 22:55, Shai Berger <[email protected]> wrote: >> > >> > Your message seems to be confusing the queryset API with the >> model-instance >> > API. >> >> Oops :-( >> >> Anyway, it seems that we agree on: >> >> - controlling this behavior in the query rather than in the field >> definition — this avoids the awkward “ignore what the field says” query >> parameter >> - trying not to provide separate APIs for insert and update behavior >> - improving the save(update_fields=…) API to support inserts as well as >> updates >> >> -- >> Aymeric. >> >> -- > 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 [email protected]. > To post to this group, send email to [email protected]. > 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/2ac56d4e-9259-4fa6-985b-4311686662b6%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/2ac56d4e-9259-4fa6-985b-4311686662b6%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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 [email protected]. To post to this group, send email to [email protected]. 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/CANJp-yiEShOwbgF2ffYp%2BCRarDv9SVFDbV4Wiu07QWQUdV%2BzvQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
