I would say its definitely not isolation level, as restarting the django instance made this issue go away for a few hours. I would setup a test for this, but don't really know if there already exist any per thread tests for django sanity I could look at for examples.
The caching change is about related models, this doesn't use any real related models, it does use them through the .values() call. Maybe this is a side affect of that caching, but that mentions nothing about the caching persisting past a single request. If that actually happens, i'm sure many people using django 1.5 are going to run into all kinds of data loss scenarios. On Tuesday, April 2, 2013 11:09:19 AM UTC-6, Alan Johnson wrote: > > It's tough to know what the deal is without any info on your code or > database, but two things come to mind. One is some of the new caching in > Django 1.5 for related models ( > https://docs.djangoproject.com/en/dev/releases/1.5/#caching-of-related-model-instances), > > and the other is database isolation level (e.g. for Postgres: > http://www.postgresql.org/docs/9.1/static/transaction-iso.html) > > On Monday, April 1, 2013 9:40:08 AM UTC-4, [email protected] wrote: >> >> So I have some stats reports that I run that it almost seems as if each >> thread has its own queryset cached. Each time I refresh they change. I'm >> going to revert back to 1.4 due to this bug. I wish I could come up with a >> simple example, to demonstrate this, the problem is that the underlying >> database needs to change between the time each thread serves a request. > > -- You received this message because you are subscribed to the Google Groups "Django users" 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 http://groups.google.com/group/django-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
