Great thanks and praises to everybody involved!
Getting down from 1346 to 204 seconds is such a relief...
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email t
As another data point, our nightly run of the test suite against
Oracle just completed. We see the same test failures we had
previously--nothing new--but it was *much* faster as hoped.
Python 2.5, Django 1.0.x: 24510 secs.
Python 2.5: Django trunk: 3024 secs.
Previously, trunk took about ten mi
On Fri, Jan 16, 2009 at 9:43 AM, Alex Gaynor wrote:
> PgSQL is indeed PostgreSQL. Yes, I do still get the failures pre-fast
> tests, I guess I'd never run those tests. I would like to say that when I
> went back to test that the tests were unbearably slow, so that makes me
> super happy about t
On Fri, Jan 16, 2009 at 9:13 AM, Ivan Sagalaev
wrote:
>
> I've found it. My fault, as usually :-). But an interesting corner case
> too.
>
> We're using mysql_replicated db backend that basically has two
> connections. The first ("master") is active by default and is used when
> loading fixtures.
On Fri, Jan 16, 2009 at 9:39 AM, Karen Tracey wrote:
> On Fri, Jan 16, 2009 at 9:15 AM, Alex Gaynor wrote:
>
>> I'm seeing some failures exclusively under PgSQL:
>> http://dpaste.com/109831/ . I'm not sure what's causing them, but it's
>> just the admin views tests, no other ones.
>>
>
> (PgSQL
On Fri, Jan 16, 2009 at 9:15 AM, Alex Gaynor wrote:
> I'm seeing some failures exclusively under PgSQL:
> http://dpaste.com/109831/ . I'm not sure what's causing them, but it's
> just the admin views tests, no other ones.
>
(PgSQL is PostgreSQL ... ?)
I see those too, on my PostgreSQL test mac
On Fri, Jan 16, 2009 at 9:13 AM, Ivan Sagalaev
wrote:
>
> Karen Tracey wrote:
> > Hmm, not sure what is going on here. Django's admin_views testscase
> > uses client and fixtures, and doesn't have a problem. It should not
> > happen that data loaded by one TestCase persists in the database to
>
Karen Tracey wrote:
> Hmm, not sure what is going on here. Django's admin_views testscase
> uses client and fixtures, and doesn't have a problem. It should not
> happen that data loaded by one TestCase persists in the database to
> another test. TestCase setup starts a transaction and disabl
On Fri, Jan 16, 2009 at 7:47 AM, Ivan Sagalaev
wrote:
>
> Karen Tracey wrote:
> > For the most part this change should be invisible, except for the speed
> > improvement when running tests. However, if you have tests that need to
> > actually test the effects of transaction commit or rollback, yo
Ivan Sagalaev wrote:
> Karen Tracey wrote:
>> For the most part this change should be invisible, except for the speed
>> improvement when running tests. However, if you have tests that need to
>> actually test the effects of transaction commit or rollback, you will
>> now need to use a django.
Karen Tracey wrote:
> For the most part this change should be invisible, except for the speed
> improvement when running tests. However, if you have tests that need to
> actually test the effects of transaction commit or rollback, you will
> now need to use a django.test.TransactionTestCase in
r9756 contains the changes to make django.test.TestCase use transaction
rollback (where available) instead of database flush/reload for resetting
the database. This can provide a nice speedup when running large test
suites -- the Django/sqlite buildbot went from around 20 minutes for the
test run
12 matches
Mail list logo
