https://twitter.com/raphaelbarrois/status/337924659666362368 worked for me, after i updated from 1.0.3 to 1.9.14
понедельник, 15 апреля 2013 г., 1:44:25 UTC+6 пользователь Ben Holloway написал: > > using uWSGI 1.0.4 for reference > > On Sunday, April 14, 2013 1:43:26 PM UTC-6, [email protected] wrote: >> >> I think this is more likely the real bug, I saw an increase in database >> connections as well. >> >> >> https://groups.google.com/forum/?fromgroups=#!topic/django-users/FxTD5M0x-G8 >> >> On Tuesday, April 9, 2013 8:06:18 AM UTC-6, Andy Dustman wrote: >>> >>> You know, I had another report of this, which seemed completely >>> improbable: >>> https://plus.google.com/u/0/101898908470597791359/posts/AuMJdgEo93k >>> >>> Maybe it's related to a bug in Django 1.5 that was fixed in 1.5.1? >>> https://www.djangoproject.com/weblog/2013/mar/28/django-151/ >>> >>> >>> On Thu, Apr 4, 2013 at 1:42 PM, <[email protected]> wrote: >>> >>>> 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. >>>> >>>> >>>> >>> >>> >>> >>> -- >>> Question the answers >>> >> -- 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. For more options, visit https://groups.google.com/groups/opt_out.
