Re: Test optimizations (2-5x as fast)

On 6/6/2011 10:19 PM, Ramiro Morales wrote: On Sun, Jun 5, 2011 at 5:18 PM, Ned Batchelder wrote: When I try this on a PostgreSQL database, I have problems relating to violated uniqueness constraints, sometimes from tests themselves, sometimes from setUpClass, sometimes

Re: Test optimizations (2-5x as fast)

On Sun, Jun 5, 2011 at 5:18 PM, Ned Batchelder wrote: > When I try this on a PostgreSQL database, I have problems relating to > violated uniqueness constraints, sometimes from tests themselves, sometimes > from setUpClass, sometimes from tearDownClass.  In the latter two

Re: Test optimizations (2-5x as fast)

On Fri, May 13, 2011 at 11:57 PM, Erik Rose wrote: > tl;dr: I've written an alternative TestCase base class which makes > fixture-using tests much more I/O efficient on transactional DBs, and I'd > like to upstream it. > [...] > 1. Class-level fixture setup > [...] > 2.

Re: Test optimizations (2-5x as fast)

On Jun 5, 2011, at 10:18 AM, Ned Batchelder wrote: > When I try this on a PostgreSQL database, I have problems relating to > violated uniqueness constraints, sometimes from tests themselves, sometimes > from setUpClass, sometimes from tearDownClass. In the latter two cases, it's > the sites

Re: Test optimizations (2-5x as fast)

On 5/17/2011 2:28 PM, Erik Rose wrote: I would be very happy to test this against Oracle database to see is how much patch improves speed since previously running tests against Oracle has been a real pain specially all db recreate stuff took a long long time. Great! I'll post again to this

Re: Test optimizations (2-5x as fast)

Here's my proposal, assuming it can be done: 1. Create default database. 2. Run a test 3. If a test has fixtures, check for, and if not, copy base table to ``name_``. 4. Start transaction 5. Run Tests 6. Roll back I think that pretty much would solve all cases, and assuming you reuse tons

Re: Test optimizations (2-5x as fast)

On 18 May 2011 01:46, Erik Rose wrote: >> Is there a sensible to way "copy" databases in SQL? > > SQL 2003 introduced CREATE TABLE x LIKE y for cloning the schema of a table. > It's supported in MySQL at least. You could then do a bunch of INSERT INTO > ... SELECTs if you

Re: Test optimizations (2-5x as fast)

> I suspect he was thinking of PostgreSQL's support for template > databases. It skips parsing overhead, so that creating a copy of a > template is roughly disk-bound. Ah yes. I've been away from my old friend Postgres for a few years. :-) -- You received this message because you are

Re: Test optimizations (2-5x as fast)

On Tue, May 17, 2011 at 6:46 PM, Erik Rose wrote: >> Is there a sensible to way "copy" databases in SQL? > > SQL 2003 introduced CREATE TABLE x LIKE y for cloning the schema of a table. > It's supported in MySQL at least. You could then do a bunch of INSERT INTO > ... SELECTs

Re: Test optimizations (2-5x as fast)

> Is there a sensible to way "copy" databases in SQL? SQL 2003 introduced CREATE TABLE x LIKE y for cloning the schema of a table. It's supported in MySQL at least. You could then do a bunch of INSERT INTO ... SELECTs if you deferred foreign key checks first. Wait, why do you want to? -- You

Re: Test optimizations (2-5x as fast)

Is there a sensible to way "copy" databases in SQL? it's pretty obvious with things like sqlite, but outside of that seems tricky. I really like that idea, and you should definitely just be able to (at the very least) run a unique hash on the required fixtures to determine if a database is

Re: Test optimizations (2-5x as fast)

On May 17, 2011, at 7:16 AM, Jonas H. wrote: > 3) Hash the SQL generated for setup/fixtures. (step in right before the SQL > is sent to the database) > Advantages: No false-positives, simple > Disadvantages: Does not eliminate the need for SQL generation and fixture > parsing + model creation,

Re: Test optimizations (2-5x as fast)

> I would be very happy to test this against Oracle database to see is how > much patch improves speed since previously running tests against Oracle > has been a real pain specially all db recreate stuff took a long long > time. Great! I'll post again to this thread when the patch is ready. Or,

Re: Test optimizations (2-5x as fast)

On Tue, May 17, 2011 at 12:59 PM, Jonas H. wrote: > On 05/17/2011 04:48 PM, Jeremy Dunck wrote: >>> >>> 1) Use file modification timestamps for all model and test related files. >>> Advantages: simple, works. >>> Disadvantages: Triggers cache invalidation for changes not related

Re: Test optimizations (2-5x as fast)

> I declare myself bike-shedding. Given the 3 options, I'm: > > +1 on #1 > +0 on #2 > -0 on #3 Heh, I was just going to quietly sit here and do that while everybody else kept mailing. :-) -- You received this message because you are subscribed to the Google Groups "Django developers" group.

Re: Test optimizations (2-5x as fast)

On 05/17/2011 04:48 PM, Jeremy Dunck wrote: 1) Use file modification timestamps for all model and test related files. Advantages: simple, works. Disadvantages: Triggers cache invalidation for changes not related to models or tests I think this is a pretty big win, even though it's not

Re: Test optimizations (2-5x as fast)

On 5/17/2011 11:31 AM, Jeremy Dunck wrote: On Tue, May 17, 2011 at 10:24 AM, Ned Batchelder wrote: Maybe it wouldn't be so bad to punt on invalidation? The cached databases would only have to be rebuilt if the models changed or if the fixtures changed, right? We have

Re: Test optimizations (2-5x as fast)

On Tue, May 17, 2011 at 10:24 AM, Ned Batchelder wrote: > Maybe it wouldn't be so bad to punt on invalidation?  The cached databases > would only have to be rebuilt if the models changed or if the fixtures > changed, right?  We have a similar situation now with migrations:

Re: Test optimizations (2-5x as fast)

On 5/17/2011 10:48 AM, Jeremy Dunck wrote: On Tue, May 17, 2011 at 9:16 AM, Jonas H. wrote: Invalidation is what I'm unsure about too -- multiple ideas came to my mind, all involving some sort of Great Hash(tm): Even within a single test command run, the same DB setup

Re: Test optimizations (2-5x as fast)

On Mon, May 16, 2011 at 10:12 PM, David Cramer wrote: > Postgres requires resetting the sequences I believe. I just assume > Oracle/MSSQL are probably similar. Actually in the Oracle backend, resetting the sequence for an empty table is currently a no-op for transactional

Re: Test optimizations (2-5x as fast)

On Tue, May 17, 2011 at 9:16 AM, Jonas H. wrote: > Invalidation is what I'm unsure about too -- multiple ideas came to my mind, > all involving some sort of Great Hash(tm): Even within a single test command run, the same DB setup and same fixture loads are done many times

Re: Test optimizations (2-5x as fast)

On 05/17/2011 01:55 PM, Ned Batchelder wrote: On 5/16/2011 11:18 PM, Erik Rose wrote: How about caching the test databases? The database state could be cached after model setup (which takes some time if you've got lots of them) + initial data fixture setup, and after the setup for each test

Re: Test optimizations (2-5x as fast)

On 5/16/2011 11:18 PM, Erik Rose wrote: How about caching the test databases? The database state could be cached after model setup (which takes some time if you've got lots of them) + initial data fixture setup, and after the setup for each test case (fixtures + setUp() method). So, in the

Re: Test optimizations (2-5x as fast)

On Fri, 2011-05-13 at 16:57 -0700, Erik Rose wrote: > tl;dr: I've written an alternative TestCase base class which makes > fixture-using tests much more I/O efficient on transactional DBs, and I'd > like to upstream it. > > Greetings, all! This is my first django-dev post, so please be gentle.

Re: Test optimizations (2-5x as fast)

> Regarding the signals, basically we have a bunch of post_save type > things, which tend to store aggregate data for certain conditions. > These get populated (in some cases) in our tests, but don't correspond > to a fixture or a model in the same app. Ah, gotcha. So, a couple solutions off the

Re: Test optimizations (2-5x as fast)

Postgres requires resetting the sequences I believe. I just assume Oracle/MSSQL are probably similar. Regarding the signals, basically we have a bunch of post_save type things, which tend to store aggregate data for certain conditions. These get populated (in some cases) in our tests, but don't

Re: Test optimizations (2-5x as fast)

Woo, thanks for the constructive suggestions! > Also, one thing I'm quickly noticing (I'm a bit confused why its > setup_class and not setUpClass as well), I was writing to nose's hooks; didn't realize Django used unittest2 now! > but this wont work with > postgres without changing the DELETE

Re: Test optimizations (2-5x as fast)

> How about caching the test databases? The database state could be cached > after model setup (which takes some time if you've got lots of them) + > initial data fixture setup, and after the setup for each test case (fixtures > + setUp() method). > > So, in the best case, no database setup is

Re: Test optimizations (2-5x as fast)

On Mon, May 16, 2011 at 7:36 PM, Erik Rose wrote: > Toward that, should I work up a Django patch, or would the core team rather I > release my work as a pluggable package? Patch, please! Fast is good :) Jacob -- You received this message because you are subscribed to the

Re: Test optimizations (2-5x as fast)

Ahoy, Alex! Thanks for the quick response. > 1. Class-level fixture setup > >> This is the one I'm most interested. I did a patch a number of months ago >> to do the fixture parsing, but not DB insertion on a per-class basis. I >> didn't find that to be a big win. However, I'm going to be

Re: Test optimizations (2-5x as fast)

On 05/14/2011 04:26 PM, Jonas H. wrote: I believe there's no generalized way of creating databases in Django now, so that would have to be added. s/creating/copying/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group,

Re: Test optimizations (2-5x as fast)

How about caching the test databases? The database state could be cached after model setup (which takes some time if you've got lots of them) + initial data fixture setup, and after the setup for each test case (fixtures + setUp() method). So, in the best case, no database setup is required

Re: Test optimizations (2-5x as fast)

More quick notes. You can do something like this to handle the flushing: sql_list = connection.ops.sql_flush(no_style(), tables, connection.introspection.sequence_list()) for sql in sql_list: cursor.execute(sql) Unfortunately,

Re: Test optimizations (2-5x as fast)

Also, one thing I'm quickly noticing (I'm a bit confused why its setup_class and not setUpClass as well), but this wont work with postgres without changing the DELETE code to work like the test runner's TRUNCATE foo, bar; (due to foreign key constraints). On May 13, 9:42 pm, David Cramer

Re: Test optimizations (2-5x as fast)

You sir, are my personal hero for the day :) We had also been looking at how we could speed up the fixture loading (we were almost ready to go so far as to make one giant fixture that just loaded at the start of the test runner). This is awesome progress On May 13, 4:57 pm, Erik Rose

Re: Test optimizations (2-5x as fast)

On Fri, May 13, 2011 at 6:57 PM, Erik Rose wrote: > tl;dr: I've written an alternative TestCase base class which makes > fixture-using tests much more I/O efficient on transactional DBs, and I'd > like to upstream it. > > Greetings, all! This is my first django-dev post, so

Test optimizations (2-5x as fast)

tl;dr: I've written an alternative TestCase base class which makes fixture-using tests much more I/O efficient on transactional DBs, and I'd like to upstream it. Greetings, all! This is my first django-dev post, so please be gentle. :-) I hack on support.mozilla.com, a fairly large Django site