Opened 11 years ago
Last modified 11 months ago
#21143 new Bug
runtests might execute queries against the normal database instead of the testdatabase
Description ¶
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.
According to the ticket's flags, the next step(s) to move this issue forward are:
- To provide a patch by sending a pull request. Claim the ticket when you start working so that someone else doesn't duplicate effort. Before sending a pull request, review your work against the patch review checklist. Check the "Has patch" flag on the ticket after sending a pull request and include a link to the pull request in the ticket comment when making that update. The usual format is:
[https://github.com/django/django/pull/#### PR]
.
Change History (6)
comment:1 by , 11 years ago
comment:2 by , 11 years ago
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)
comment:3 by , 11 years ago
Oh OK, my mistake, now I understand, "our testrunner" is the Django's testrunner. I'll check the fix.
comment:5 by , 8 years ago
Yeah, we might check if we can delay test discovery till settings are configured properly (ie for testing)
comment:6 by , 11 months ago
Cc: | added |
---|
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.