I didn't know queryset.update did clear the internal cache. In that case
it's pretty reasonable. I think it should only clear a .all() cache though,
not any prefetched set.

On 7 June 2016 at 22:38, Florian Apolloner <[email protected]> wrote:

> Same feeling as Carl here. I was probably the first to get asked whether
> or not this was a bug or not on IRC and my initial thought was also "wtf,
> that is clearly a bug" -- hence I asked Yoong Kang Lim to open a ticket.
>
> Cheers,
> Florian
>
>
> On Tuesday, June 7, 2016 at 7:47:29 PM UTC+2, Carl Meyer wrote:
>>
>> On 06/07/2016 06:11 AM, Marc Tamlyn wrote:
>> > 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().
>>
>> Hmm, I have the opposite instinct. I don't find it analogous to the case
>> of some unrelated queryset object failing to update its internal cache
>> when the database changes. In this case we have a related-manager with
>> an internal cache, and we make changes _via that same manager_. I find
>> it quite surprising that the manager doesn't automatically clear its
>> cache in that case.
>>
>> A much stronger precedent, I think, is the fact that Queryset.update()
>> does clear the queryset's internal result cache. In light of that, I
>> think the current behavior with prefetched-data on a related manager is
>> a bug that should be fixed (though it certainly should be mentioned in
>> the release notes).
>>
>> Carl
>>
>> --
> 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/61cce517-3117-42ec-aceb-de8bb3a7b7cc%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/61cce517-3117-42ec-aceb-de8bb3a7b7cc%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/CAMwjO1H0%3D%2BKefZPwBCkBx5rX722rjp84n5Re2mSLYSAVtq74yA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to