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.apollo...@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-developers+unsubscr...@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/CAHoz%3DMa2DVUXHotoHW_XB91eW6imgV_Evc%2B4-ApFqwACEa0jnA%40mail.gmail.com.
