Opened 18 months ago

Closed 18 months ago

Last modified 18 months ago

#22189 closed New feature (needsinfo)

autotesting is very slow

Reported by: yidao620c Owned by: nobody
Component: Database layer (models, ORM) Version: 1.6
Severity: Normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

When running the testcases, I suggest do not auto create/drop a test database according to the settings.py, but only the sqlite instead. I think this will be faster.

Change History (2)

comment:1 Changed 18 months ago by russellm

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to needsinfo
  • Status changed from new to closed

Thanks for the suggestion.

However:

  • The test database is only created at the start of the test run, not at the start of every test.
  • We need to have a guaranteed clean test environment for each test run, and the easiest way to do this is to create a new test database each time.

If you think you have a faster way to run the tests, the onus is on you to prove it! You can do this by providing a patch (either a fully worked patch, or a proof-of-concept patch) with timings showing what the speedup would be, and what unexpected consequences of your approach exist (if any).

comment:2 Changed 18 months ago by shai

There can be reasons to use an existing "database" -- for example, on PostgreSQL and Oracle this allows one to control the tablespace to be used by the tests. In fact, on Oracle this is already supported (Oracle does not have databases in the sense of PostgreSQL, and the relevant settings actually refer to tablespaces), and I think supporting it on Postgres too is a good idea.

However, even under these circumstances, it is usually desirable to use a new "schema" in the database; and it is the generation of objects in this schema that takes most of the time in creating and dropping test databases. So, testing speed should not change significantly.

On MySQL, "schema" is synonymous with "database", and the concept of "tablespace" only exists for specific (cluster) storage types, so this doesn't make much sense anyway.

Note: See TracTickets for help on using tickets.
Back to Top