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.
