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, budl...@gmail.com 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 django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
