Re: Performance regression when moving from 3.1 to 3.2 (same with 4)

Can you dump the generated sql from both Django versions? https://docs.djangoproject.com/en/4.1/faq/models/#how-can-i-see-the-raw-sql-queries-django-is-running On September 1, 2022 8:58:08 AM CDT, Marc Parizeau wrote: >Hi, > >I am seing a sharp increase in execution time for some of my queries w

Performance regression when moving from 3.1 to 3.2 (same with 4)

Hi, I am seing a sharp increase in execution time for some of my queries when moving from Django 3.1 to 3.2. And the performance hit appears to be the same for Django 4. My backend is Postgres 14.2. My Django project has forums for different types of content. The forum app consists essential

Re: DB foreign key constraints : Django 1.7 regression ?

Ticket created at https://code.djangoproject.com/ticket/23741 , with a basic implementation (that detected missing relations on non-managed models on my project !!). Thanks for the help ! Le jeudi 30 octobre 2014 18:28:31 UTC+1, Carl Meyer a écrit : > > On 10/30/2014 06:09 AM, not...@gmail.com

Re: DB foreign key constraints : Django 1.7 regression ?

On 10/30/2014 06:09 AM, nots...@gmail.com wrote: > Thanks Daniel, that was it (instead of removing the migrations folder, I > now use makemigrations). > > I expected everything to work without the need of migrations. > So I guess that with django 1.7, it is simply mandatory to use migrations. > >

Re: DB foreign key constraints : Django 1.7 regression ?

efined after "django.contrib.contenttypes" and >> "django.contrib.auth" in INSTALLED_APPS. >> Putting "django.contrib.contenttypes" as my last app does not change the >> DB construction. >> >> So does it have to do with the order in INSTALLED_APPS

Re: DB foreign key constraints : Django 1.7 regression ?

ypes" and > > "django.contrib.auth" in INSTALLED_APPS. > > Putting "django.contrib.contenttypes" as my last app does not change the > > DB construction. > > > > So does it have to do with the order in INSTALLED_APPS ? > > Is it a regress

Re: DB foreign key constraints : Django 1.7 regression ?

; "django.contrib.auth" in INSTALLED_APPS. > Putting "django.contrib.contenttypes" as my last app does not change the > DB construction. > > So does it have to do with the order in INSTALLED_APPS ? > Is it a regression ? > > Thanks for the input ! > >

Re: DB foreign key constraints : Django 1.7 regression ?

uot; in INSTALLED_APPS. > Putting "django.contrib.contenttypes" as my last app does not change the > DB construction. > > So does it have to do with the order in INSTALLED_APPS ? > Is it a regression ? I don't have time to look into this and try to reproduce at

DB foreign key constraints : Django 1.7 regression ?

- django_site My local apps are always defined after "django.contrib.contenttypes" and "django.contrib.auth" in INSTALLED_APPS. Putting "django.contrib.contenttypes" as my last app does not change the DB construction. So does it have to do with the order in INSTA

Re: regression? validate_email accepts trailing dash

a bug. > > In django 1.6 an EmailField will accept an address of the form > 'f...@bar.com-' > In django 1.4 it would trigger a ValidationError. > > Should this be considered a regression? > > The way I interpret the email domain name specs f...@bar.com- is &g

regression? validate_email accepts trailing dash

Hi everybody, I've found this behavior that feels like a bug. I would like your opinion on whether it *is* a bug. In django 1.6 an EmailField will accept an address of the form 'f...@bar.com-' In django 1.4 it would trigger a ValidationError. Should this be considered a regress

Re: Regression in blocktrans tag parsing between 1.2 and 1.3

On Thu, Oct 27, 2011 at 7:05 PM, SmileyChris wrote: > I think this may be that the previous format worked but wasn't really > supported. > The 1.2 documentation on the blocktrans tag says: >> >> Designate and bind a counter value with the name count >> >> [...] >> >> A more complex example: >> {%

Re: Regression in blocktrans tag parsing between 1.2 and 1.3

I think this may be that the previous format worked but wasn't really supported. The 1.2 documentation on the blocktrans tagsays: > Designate and bind a counter value with the name count [...] A

Regression in blocktrans tag parsing between 1.2 and 1.3

Hi all Django 1.3's blocktrans tag is documented as still supporting 1.2's more verbose syntax. However, if you attempt a plural translation, it barfs. More importantly, it rejects a format that 1.2 accepts, and accepts a format that 1.2 rejects. This format is rejected by 1.2 and accepted by 1.3

Re: InterfaceError: Connection already closed -- is this a regression?

I hear you, Russ. I'll see if I can't get something more repeatable down in code, but as I stated, it's an intermittent problem. Didn't meant to sound like your 3rd option wasn't an option ("issues with the code" is always an option). I just wanted to make sure this wasn't a "postgres thing" that I

Re: InterfaceError: Connection already closed -- is this a regression?

On Wed, Mar 2, 2011 at 11:46 PM, onelson wrote: > I recently switched a project from mysql to postgres and started to > see httpd throwing intermittent 500 errors. > > mod_wsgi (pid=26467): Exception occurred processing WSGI script '/ > htdocs/django.wsgi'. >  Traceback (most recent call last)

Re: InterfaceError: Connection already closed -- is this a regression?

I'm having the exact same issue and haven't found any answers either. I'll update if I find something as well. On Mar 2, 11:46 am, onelson wrote: > I recently switched a project from mysql to postgres and started to > see httpd throwing intermittent 500 errors. > > mod_wsgi (pid=26467): Exception

InterfaceError: Connection already closed -- is this a regression?

I recently switched a project from mysql to postgres and started to see httpd throwing intermittent 500 errors. mod_wsgi (pid=26467): Exception occurred processing WSGI script '/ htdocs/django.wsgi'. Traceback (most recent call last): File "./lib/python2.6/site-packages/django/core/han

Re: run single regression test from test suite

On Sun, Mar 14, 2010 at 12:14 PM, ben wrote: > I haven't been able to work out how to run a single regression test > from the test suite. > > I would have thought that > > ./runtests.py --settings=test_sqlite > regressiontests.generic_relations_regress.tests.GenericRe

run single regression test from test suite

I haven't been able to work out how to run a single regression test from the test suite. I would have thought that ./runtests.py --settings=test_sqlite regressiontests.generic_relations_regress.tests.GenericRelationTests might work. But it expects tests of the form app.TestCase. Since

Regression

What are best practices to regress django views? -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegr

Re: Caching performance regression between django 1.0 and django 1.1.1

le as > >> > default to be called. > >> > In the case where that callable is an expensive operation the > >> > performance is severely affected. > >> > I've created patches showing this regression for the branches > >> >http://code.django

Re: Caching performance regression between django 1.0 and django 1.1.1

le as > >> > default to be called. > >> > In the case where that callable is an expensive operation the > >> > performance is severely affected. > >> > I've created patches showing this regression for the branches > >> >http://code.django

Re: Caching performance regression between django 1.0 and django 1.1.1

database queries using memcached, in >> > django 1.0 reading from the cache is a fast operation however in >> > django 1.1.1 reading from cache causes all fields with a callable as >> > default to be called. >> > In the case where that callable is an expensi

Re: Caching performance regression between django 1.0 and django 1.1.1

er in > > django 1.1.1 reading from cache causes all fields with a callable as > > default to be called. > > In the case where that callable is an expensive operation the > > performance is severely affected. > > I've created patches showing this regression for th

Re: Caching performance regression between django 1.0 and django 1.1.1

er in > > django 1.1.1 reading from cache causes all fields with a callable as > > default to be called. > > In the case where that callable is an expensive operation the > > performance is severely affected. > > I've created patches showing this regression for th

Re: Caching performance regression between django 1.0 and django 1.1.1

to be called. > In the case where that callable is an expensive operation the > performance is severely affected. > I've created patches showing this regression for the branches > http://code.djangoproject.com/svn/django/branches/releases/1.0.X > and > http://code.djangoproject.com

Caching performance regression between django 1.0 and django 1.1.1

ected. I've created patches showing this regression for the branches http://code.djangoproject.com/svn/django/branches/releases/1.0.X and http://code.djangoproject.com/svn/django/branches/releases/1.1.X which shows the default callable being called on cache read. My questions are: 1. Is it wron

Caching performance regression between django 1.0 and django 1.1.1

ected. I've created patches showing this regression for the branches http://code.djangoproject.com/svn/django/branches/releases/1.0.X and http://code.djangoproject.com/svn/django/branches/releases/1.1.X which shows the default callable being called on cache read. My questions are: 1. Is it wron

Re: Running just core regression tests

On Mon, Oct 12, 2009 at 6:24 PM, Tim Chase wrote: > > Last year, the wifey finally convinced me to let go of the even > older machine (133MHz with 96 megs of memory and a 800x600 CRT :) > running OpenBSD. > > Yeah, you've got me beat. I do still have the IBM AT I had in college, with its roomy 10

Re: Running just core regression tests

>> On my oldest slowest machine (7 year old WinXP box with 384M of memory), >> Then you're not far off -- my home work-horse is an 8-year-old >> Celeron laptop clocked at 800MHz with 384M of memory running >> Debian off a fairly slow HDD. > > My 800MHz Celeron laptop got retired about a year ago

Re: Running just core regression tests

On Sun, Oct 11, 2009 at 7:40 PM, Tim Chase wrote: > > > On my oldest slowest machine (7 year old WinXP box with 384M of memory), > > Then you're not far off -- my home work-horse is an 8-year-old > Celeron laptop clocked at 800MHz with 384M of memory running > Debian off a fairly slow HDD. My 8

Re: Running just core regression tests

>> t...@rubbish:~/django/trunk/tests$ python runtests.py >> --settings=settings >> >> to execute the core set of tests. However, it takes quite a >> while (on the order of hours) on my old box. Is there a way to >> just run tests on the regressions/ subdirectory or even just a >> particular file

Re: Running just core regression tests

On Sat, Oct 10, 2009 at 11:41 AM, Tim Chase wrote: > > Currently, I use > > t...@rubbish:~/django/trunk/tests$ python runtests.py > --settings=settings > > to execute the core set of tests. However, it takes quite a > while (on the order of hours) on my old box. Is there a way to > just run test

Re: Running just core regression tests

here a way to > just run tests on the regressions/ subdirectory or even just a > particular file within? > > How do core devs typically make testing a subset faster? There's no way to say "just run the tests in the regression directory", but you can use the same tricks

Running just core regression tests

Currently, I use t...@rubbish:~/django/trunk/tests$ python runtests.py --settings=settings to execute the core set of tests. However, it takes quite a while (on the order of hours) on my old box. Is there a way to just run tests on the regressions/ subdirectory or even just a particular fi

Re: Regression tests and TestCase method

Hello! > I guess that the test runner tries to call "test_bla()" automatically. > How can I prevent that? Is it possible to move tast_bla() method to other class? You can create an instance of this class in the setUp() method of SomeTest and use it in all test cases. --~--~-~--~~

Re: Regression tests and TestCase method

On Wed, Jun 25, 2008 at 8:55 AM, Julien <[EMAIL PROTECTED]> wrote: > > I guess that the test runner tries to call "test_bla()" automatically. > How can I prevent that? You can't. This is by design of unittest.TestCase - any method starting with 'test_' is found an executed as a test case. The wo

Regression tests and TestCase method

Hi, I'm making some regression tests for Django, and there's a problem I can't get around. Here's the code: class SomeTest(TestCase): def test_bla(self, an_argument): def test_something(self): self.test_bla("blablabla&quo

Regression with QS-RF

I have a queryset with .extra call where I do something like this, self.get_query_set().extra ... tables=['news_topic as permission_table'] .. Pre qs-rf, the values in tables were not being escaped and so this was working, with qs-rf the value in tables is escaped, so my code fails.

regression: Custom Upload Fields

The Custom Upload Fields and Filters at http://code.djangoproject.com/wiki/CustomUploadAndFilters/ (currently version 8) is now broken in the django development version. When you upload an image to a new object in the AutoFileField or AutoImageField, it gets saved with the filename as "None.jpg