I may be "too close" to knowing the implementation of this feature to be able to comment on whether the behaviour is surprising to most people, but it doesn't surprise me. It's certainly analogous to that when you do `MyModel.objects.create()` it doesn't change an already executed queryset. There's a question of where you draw the line as well - what about `related_set.update()`?
I think it's worth documenting the behaviour, also noting that you can "force" the execution of a new queryset by chaining another .all(). On 7 June 2016 at 13:26, Yoong Kang Lim <[email protected]> wrote: > Hi all, I'd like to bring up ticket #26706: > https://code.djangoproject.com/ticket/26706 > > Related managers have methods such as add(), change() and remove() that > change database objects. When a prefetch_related is done prior to calling > these methods, it does not clear the cache. When the related field is > accessed, it returns the cached result instead of the updated result. A > couple of tickets have been opened, as this does seem to be surprising > behaviour. > > I was working on a patch to address this, but Tim brought up some concerns > about backward compatibility regarding the change and directed me here to > get some community consensus. The change I'm proposing will clear the cache > (for the prefetched field) when any of the methods are called. If we > introduce this, it will be a backwards-incompatible change, so I'd just > like to get some opinions on what the best way forward would be. Obviously > in either case the behaviour should be documented. > > Also a thought just occurred to me -- if we don't put this change in, > could we, as an alternative solution, extend the API to let the user decide > what to do with the cache? Maybe something like > clear_prefetched_field(related_field_name) on the manager so that at least > the user has a choice instead of running the query (although the trouble > they would need to go through would be similar, IMO). > > -- > 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 [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/eabd9567-53e3-413b-9b30-dbcfbf9c2634%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/eabd9567-53e3-413b-9b30-dbcfbf9c2634%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMwjO1EkD_gfr6rGrFe%3DGY5YRXCs5qYoKYmw8zST94GLJOHECA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
