here, which has a lot of crossover.
If there was a desire to support UPDATE RETURNING for the `Model.save()`
method, were there any thoughts in relation to having a similar/consistent
API to what's being proposed here for `QuerySet.update()` method?
I believe currently the preferred sug
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
gene
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.
Ret
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,
retur
Bien
Le lun. 25 sept. 2023 à 17:44, Aivars Kalvāns 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, *, retur
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 exi
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, usern
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
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...
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 s
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
>
> 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.obj
Not that I am completely convinced that the following is a good idea; but
what about:
QuerySet.objects.update(name="Rob").values("id", "name")
On second thought I'd like an .returning() more than values, but I am not
sure if it makes sense to add a new function just for the sake of a small
bac
I think we could do the most logical:
QuerySet.objects.update(name="Rob", returning=["id', "name"])
There is a precedent for small backwards incompatible changes like this,
for example when "named" was added to "values_list()". However maybe
backwards compatibility is worth keeping. We can be bac
Hi,
I found myself with a use-case today of wanting to return some data from an
update, as I want to make sure I return exactly what is in the database
without making an extra query.
I've found https://code.djangoproject.com/ticket/28682 and agree with the
resolution there.
I suppose there is a
15 matches
Mail list logo
