If we were to change the update signature from (**updates) to
(updates=None, *, returning=None, **kwargs) the `returning` collision could
be avoided by doing update({"foo": "bar"}, returning=["id", "foo"]) like
Tom is suggesting.
I think that's the best option here if we want to elegantly add support for
this feature while maintaining backward compability. Something along the
lines of
def update(updates=None, *, returning=None, **kwargs):
if updates and kwargs:
raise TypeError('updates must be either specified through the first
positional argument or kwargs')
if updates is None:
updates = kwargs
...
I guess we could force the usage of positional `updates` if `returning` is
specified to prevent any silent breakages as well.
The usage of `returning` bring another set of questions though. Since
UPDATE are not ordered RETURNING data has little value without the primary
key associated with the updated rows. Maybe the return value of
`returning=[f1, ..., fn]` should be a dict mapping the primary key to list
of returning values.
e.g.
Post.objects.create(id=1, score=41)
Post.objects.update({"score": F("score") + 1}, returning=["score"])
-> {1: [42]}
Cheers,
Simon
Le mardi 26 janvier 2021 à 12:36:10 UTC-5, f.apo...@gmail.com a écrit :
> On Tuesday, January 26, 2021 at 5:26:02 PM UTC+1 Adam Johnson wrote:
>
>> Not that I am completely convinced that the following is a good idea; but
>>> what about:
>>
>> QuerySet.objects.update(name="Rob").values("id", "name")
>>>
>>
>> That's not possible since update() directly performs the update - it's
>> not lazy in any way. It could be done in the other order like
>> `QuerySet.objects.values("id", "name").update(name="Rob")` but I don't see
>> the necessity to define "returning" fields in a chainable manner.
>>
>
> Ha, not sure what I was thinking. The sentence below I noted that update()
> would return something but I didn't think that this would break chaining.
> My bad.
>
> I looked further around and `get_or_create` has the nice workaround of
> being able to use `defaults__exact` if it clashes with the `defaults`
> keyword. Sadly we do not have that option here. Truth to be told I do not
> think that many people have fields called returning
>
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/86210b9b-4978-4068-ac61-f1a3061bf2a4n%40googlegroups.com.
