Usually, yes. I'm not sure refresh_from_db works on related managers
though. I ran into a similar issue writing unit test fixtures just last
week and refresh_from_db didn't fix the problem.
On Thursday, 9 June 2016 02:46:25 UTC+10, bliy...@rentlytics.com wrote:
>
> To be clear, I think the way
Hi everyone,
I've started on an "official projects" process DEP as I discussed here a
while back, to formalise the process of adopting non-core packages as
repositories under the official Django organisation, with a view to taking
Channels on this route (and hopefully including the existing localf
To be clear, I think the way to force the refresh of an orm object is to
use the `refresh_from_db` method. Is that functionally equivalent?
-Ben
On Tuesday, June 7, 2016 at 6:12:30 AM UTC-7, Marc Tamlyn wrote:
>
> I may be "too close" to knowing the implementation of this feature to be
> able
I am for the clearing of the cache--that behavior seems weird. If you
didn't want the cache to clear you would probably be using a different orm
object to do your query.
Just to be clear, after clearing the cache, any future requests against
that data will be lazily evaluated right?
-Ben
On
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 wrote:
> Same feeling as Carl here. I was probably the first to get asked whethe
