Opened 17 months ago

Last modified 5 months ago

#32406 new New feature

Allow QuerySet.update() to return fields on supported backends.

Reported by: Tom Carrick Owned by:
Component: Database layer (models, ORM) Version: dev
Severity: Normal Keywords:
Cc: Diego Lima, Johannes Maron Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


Mailing list

For example:

Foo.objects.update(x="abc", returning=["pk", "x"])

To return something like:

    {"pk": 1, "x": "abc"},
    {"pk": 2, "x": "abc"},
    {"pk": 3, "x": "abc"},

The exact API and implementation is still a little unclear, but there seems to be support for doing something.

Change History (9)

comment:1 Changed 17 months ago by Tom Carrick

Owner: changed from nobody to Tom Carrick

comment:2 Changed 17 months ago by Carlton Gibson

Triage Stage: UnreviewedAccepted

OK, I'll provisionally accept on the basis of the discussion.
It would be good if we could pin down an API that was generally agreed upon (ref the return value seems the main sticking point) before implementation began.

comment:3 Changed 17 months ago by Chris Jerdonek

Recently, on issue #32381 about bulk_update(), I suggested the idea of returning different values as attributes of a single result object (e.g. a namedtuple). That was about bulk_update() rather than update(), but the principle is the same. In this case, the two possible values under consideration could be approximately named something like number_matched and values.

comment:4 Changed 16 months ago by Diego Lima

Cc: Diego Lima added

comment:5 Changed 13 months ago by Johannes Maron

Cc: Johannes Maron added

comment:6 Changed 13 months ago by Johannes Maron

Hi there, I implemented the returning support in the past. I believe this feature is possible, however, I think we need to be sure how this differs from setting db_returning on the fields itself. In case you didn't know (it's not documented yet) You have multiple return values by setting that attribute to true. I would be curious if you could provide a more detailed use case. Best, Joe

FYI, this might be somewhat related to #30032 and #470

comment:7 Changed 13 months ago by Tom Carrick

Johannes, I originally saw a couple of use-cases:

  1. There is some before update trigger that changes the data. If I understand it, db_returning should cover this (I had no idea it existed as it's not documented).
  2. You are creating an API (or not an API) with a bulk update feature, and you want to return the results to the user without making another query to gather them.

comment:8 Changed 13 months ago by Johannes Maron

Hi there,

Interesting cases. DB triggers make things slightly more difficult as the db_returning feature is currently only tested for inserts not updates.

I would see two things here, first, to add db_retuning support to a save call (single object update). Second, you could build on those API changes to add this functionality to update.
Honestly, with #470 on its way. It stands to reason, if it made sense to refresh and object from the database by default. But that's a mailing list discussion for future me ;)

In any event, this proposal seems justified to me. If you find the time to tackle it, I am happy to help out with reviews.


comment:9 Changed 5 months ago by Tom Carrick

Owner: Tom Carrick deleted
Status: assignednew
Note: See TracTickets for help on using tickets.
Back to Top