I think it's okay to return something else based on a parameter. This is
already done for e.g. values_list(flat=True) and values_list(named=True).
While the bool addresses the obvious footgun I think it also loses a lot of
flexibility. If you have a field modified by a pre-update trigger or a
generated field that uses a field you updated, you wouldn't be able to see
these without another query, as I understand it.
On Sat, 7 Oct 2023 at 19:20, aivars.kalv...@gmail.com <
aivars.kalv...@gmail.com> wrote:
> Hi!
>
> I considered making `returning: bool` a flag that we are returning data.
> That would make it `Foo.objects.update(x=1, y=2, returning=True)` and
> avoid some footguns. Or even a new function (`update_returning`?) because I
> have mixed feelings about different return types based on parameters.
>
> Returning fields other than ones updated is a valid case IMO: we can
> update some records and return the PKs of updated records for logging
> instead of having just the number of rows updated. Something
> like`.values_list('pk', flat=True)` is useful then.
>
>
>
>
>
> On Sat, Oct 7, 2023 at 6:46 PM Tom Carrick <t...@carrick.eu> wrote:
>
>> Hi Aivars,
>>
>> Since we spoke yesterday I've been thinking about this...
>>
>> I don't really see the value in returning a QuerySet. There are only a
>> limited number of options that make sense at this point, and even those are
>> tough to justify. Like what would happen if you do `Foo.objects.update(x=1,
>> returning=["x"]).values("y")`?
>>
>> I do see value in returning the model instances, though I feel there is a
>> potential footgun here where you can update a field, but not return it, so
>> you'd get the old value in the instance. Something like:
>>
>> `Foo.objects.update(x=1, y=2, returning=["x"])`
>>
>> Now you have updated y, but the model instance that gets returned still
>> has the old value. Maybe this is fine with a warning in the docs.
>>
>> I think regardless of what we do here, we should stick with the proposed
>> and roughly agreed upon API of having an extra argument to `update()`
>> rather than creating a new QuerySet method.
>>
>> Cheers,
>> Tom
>>
>>
>> On Tue, 3 Oct 2023 at 23:38, Plamedi klj <plamedikl...@gmail.com> wrote:
>>
>>> Bien
>>>
>>> Le lun. 25 sept. 2023 à 17:44, Aivars Kalvāns <aivars.kalv...@gmail.com>
>>> a écrit :
>>>
>>>> Hi!
>>>>
>>>> I want to implement these changes and I have a PR in the ticket
>>>> https://code.djangoproject.com/ticket/32406
>>>> At the moment I have a new `update_returning` method but I can easily
>>>> replace it with ` (updates=None, *, returning:bool=None, **kwargs)` if you
>>>> decide to add functionality to the existing method instead. I did a search
>>>> on github and found only a single project with `returning` as model field.
>>>> However the returned value in my implementation is a `QuerySet` and I
>>>> can do `.get()`, `.only()`, `.defer()` and `.values()` or `.values_list()`
>>>> on that. Mainly because my use case is updating and refreshing the model in
>>>> a single database operation. The ticket has more examples. What do you
>>>> think, do you see any issues with this approach?
>>>>
>>>> trešdiena, 2021. gada 12. maijs 15:18:50 UTC+3 Tom Carrick rakstīja:
>>>>
>>>>> Apologies, I had totally forgotten about this, but I'm still
>>>>> interested in working on it, but still not sure about a few things.
>>>>>
>>>>> I've been thinking about the return value a bit. I can foresee cases
>>>>> where you wouldn't want the id returned. You might want the user to
>>>>> update
>>>>> something by slug, username, or some other identifier without revealing
>>>>> the
>>>>> IDs. Of course the user could reformat the return value however they like,
>>>>> but I don't see a reason to ask for something that isn't necessary.
>>>>>
>>>>> So I think a list of some kind of object (namedtuple or dict probably)
>>>>> makes the most sense to me. As for also adding the count, I am not sure.
>>>>> The return value would then be e.g. (1, [<data>]). I'm guessing this count
>>>>> would remain as the number of matched rows, rather than the updated ones -
>>>>> I am not sure if returning only gives back rows that were modified or not,
>>>>> the Postgres docs are at least unclear on this. If they're always going to
>>>>> be the same, I'm not sure there is much reason for returning the count
>>>>> when
>>>>> len(return_value) will do.
>>>>>
>>>>> I'm also not really sure on the data structure though. Namedtuples
>>>>> make the most sense to me but a dict might be useful for those wanting to
>>>>> shove this directly into JsonResponse, without needing _asdict(), for
>>>>> example.
>>>>>
>>>>> Cheers,
>>>>> Tom
>>>>>
>>>>> On Wed, 27 Jan 2021 at 10:45, Florian Apolloner <f.apo...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi Simon,
>>>>>>
>>>>>> On Wednesday, January 27, 2021 at 5:54:42 AM UTC+1 charettes wrote:
>>>>>>
>>>>>>> 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 ...
>>>>>>>
>>>>>>
>>>>>> That is certainly an interesting approach. It kinda breaks the "there
>>>>>> should be one way of doing things" rule, but…
>>>>>>
>>>>>> 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.
>>>>>>>
>>>>>>
>>>>>> I am not sure I like that. For things where you update just one row
>>>>>> and want to know the new values the primary key doesn't make much sense.
>>>>>> Granted for multiple rows it would maybe easier to have it automatically
>>>>>> keyed by the pk, but returning something always (the pk) without having
>>>>>> an
>>>>>> option to disable it seems kinda wrong to me. Not sure what the best
>>>>>> option would be.
>>>>>>
>>>>>> Cheers,
>>>>>> Florian
>>>>>>
>>>>>> --
>>>>>>
>>>>> 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-develop...@googlegroups.com.
>>>>>>
>>>>> To view this discussion on the web visit
>>>>>> https://groups.google.com/d/msgid/django-developers/4eea605a-57d7-4ce3-b233-3eb88c91e110n%40googlegroups.com
>>>>>> <https://groups.google.com/d/msgid/django-developers/4eea605a-57d7-4ce3-b233-3eb88c91e110n%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/ee284d47-6181-426d-98fd-3a0e50e0d9abn%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/django-developers/ee284d47-6181-426d-98fd-3a0e50e0d9abn%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/CABZ%3D34ic1y%3D7J3hhsGDauVtfF0B6RW10htugQmD-mbE0sf%2BY_Q%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/django-developers/CABZ%3D34ic1y%3D7J3hhsGDauVtfF0B6RW10htugQmD-mbE0sf%2BY_Q%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/django-developers/qQ5DT91nBLM/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, 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%3DMaWtPtsJhZp2m_am8acrOTkSHPzKZpP1iTf83PwxtUKGA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/django-developers/CAHoz%3DMaWtPtsJhZp2m_am8acrOTkSHPzKZpP1iTf83PwxtUKGA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>
>
> --
> Aivars
>
> --
> 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/CAC2VC9jN%3Da6_QhKggLCzPh3mJCmLCQbSZgwew6A%3D0KB8mCTBjA%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAC2VC9jN%3Da6_QhKggLCzPh3mJCmLCQbSZgwew6A%3D0KB8mCTBjA%40mail.gmail.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%3DMYdfvg9g-3-1Y5z%3DRLHigvsMzmFFSVSq07FEVoBbXVgcg%40mail.gmail.com.
