runtests might execute queries against the normal database instead of the testdatabase

[Florian Apolloner]

The way our testrunner currently works is that it constructs the test classes before creating the test database and resetting the database names. This causes module level queries (which you shouldn't have, but…) to be executed against the main database resulting in errors like:

Traceback (most recent call last):
  File "/usr/lib/python3.3/unittest/case.py", line 384, in _executeTestPart
    function()
  File "/usr/lib/python3.3/unittest/loader.py", line 32, in testFailure
    raise exception
ImportError: Failed to import test module: transactions_regress.tests
Traceback (most recent call last):
  File "/var/lib/jenkins/jobs/Django/workspace/database/mysql_gis/python/python3.3/django/db/utils.py", line 101, in inner
    return func(*args, **kwargs)
  File "/var/lib/jenkins/jobs/Django/workspace/database/mysql_gis/python/python3.3/django/db/backends/mysql/base.py", line 131, in execute
    return self.cursor.execute(query, args)
  File "/usr/local/lib/python3.3/dist-packages/MySQL_python-1.2.3-py3.3-linux-x86_64.egg/MySQLdb/cursors.py", line 185, in execute
    self.errorhandler(self, exc, value)
  File "/usr/local/lib/python3.3/dist-packages/MySQL_python-1.2.3-py3.3-linux-x86_64.egg/MySQLdb/connections.py", line 37, in defaulterrorhandler
    raise errorvalue
  File "/usr/local/lib/python3.3/dist-packages/MySQL_python-1.2.3-py3.3-linux-x86_64.egg/MySQLdb/cursors.py", line 172, in execute
    r = self._query(query)
  File "/usr/local/lib/python3.3/dist-packages/MySQL_python-1.2.3-py3.3-linux-x86_64.egg/MySQLdb/cursors.py", line 332, in _query
    rowcount = self._do_query(q)
  File "/usr/local/lib/python3.3/dist-packages/MySQL_python-1.2.3-py3.3-linux-x86_64.egg/MySQLdb/cursors.py", line 296, in _do_query
    db.query(q)
_mysql_exceptions.OperationalError: (1050, "Table 'INTROSPECT_TEST' already exists")

In the case above this is caused by two parallel testruns against different TEST_NAMEs but the same NAME in the database config. It would be nice if we could fix that.

[Pablo SEMINARIO]

Can you provide a minimal test project (settings and your testrunner) in which the queries are executed again the normal database?
So that the problem can be reproduced and investigated.

[Florian Apolloner]

There is no need for a testproject, since this can be exposed by Django's testsuite itself… See the current fix in ​https://github.com/django/django/commit/4fcc1e4ad8d153f41132b171c231b6d5d4086c28 (I refed the ticket there, but apperently trac didn't pick it up)

[Pablo SEMINARIO]

Oh OK, my mistake, now I understand, "our testrunner" is the Django's testrunner. I'll check the fix.

[Tim Graham]

Florian, are there any other action items for this ticket?

[Florian Apolloner]

Yeah, we might check if we can delay test discovery till settings are configured properly (ie for testing)