Simon, you give me too much credit, that is step beyond what I'd thought of
:) It looks good to me.
Why not a dict of dicts or perhaps a dict of namedtuples instead? I think a
list might be a bit annoying to map back to the requested fields.
Maybe I will try to put a proof of concept together...
Tom
On Wed, 27 Jan 2021 at 05:54, charettes <charett...@gmail.com> wrote:
> 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
> <https://groups.google.com/d/msgid/django-developers/86210b9b-4978-4068-ac61-f1a3061bf2a4n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAHoz%3DMbQgTjar9QKWdhdQt8GcnVZVko8OyEO6K9ci1%3Dq_90Q7Q%40mail.gmail.com.
