Why are django parameters imported twice and a test database created twice during unit tests?

Django: 1.3; PyCharm: 1.5.3

I am writing unit tests for a Django application that uses GEOS to store Point objects. For local testing, I followed every step in setting up the Spatialite backend according to the GeoDjango documentation.

I came across GEOS_ERROR (GEOS_ERROR: Geometry must be Point or LineString) whenever I tried to create and save a model instance with a Point object. It was clear that the Point object was indeed passed in the get_or_create function for the model. And the same model can be saved without problems in the shell.

Without going into the code that caused this error, I found that every time I run unit test, Django imported the settings, created the test database and immediately destroyed the database, and then again created the test database for the tests that ultimately will cause errors.

Testing started at 5:09 PM ...<br /> Importing Django settings module settings SpatiaLite version ..: 2.4.0 Supported Extensions: - 'VirtualShape' [direct Shapefile access] - 'VirtualText'[direct CSV/TXT access] - 'VirtualNetwork [Dijkstra shortest path] - 'RTree' [Spatial Index - R*Tree] - 'MbrCache' [Spatial Index - MBR cache] - 'VirtualFDO' [FDO-OGR interoperability] - 'SpatiaLite' [Spatial SQL - OGC] PROJ.4 Rel. 4.7.1, 23 September 2009 GEOS version 3.3.0-CAPI-1.7.0Creating test database 'default'... Destroying old test database 'default'... SpatiaLite version ..: 2.4.0 Supported Extensions: (same Spatialite settings again) cannot start a transaction within a transaction cannot rollback transaction - SQL statements in progress Syncing... Creating tables ... 

I suspected this was caused by PyCharm. But when I run "python manage.py test" from the terminal shell, the same process repeated and the same errors were thrown.

I checked my settings file, but could not find out why it requests import twice and why the test database was created twice. Required init_spatialite-2. *. Sql for creating Spatialite database is also on the way to the project.

Any advice would be highly appreciated!

Update : I was notified by JetBrains that importing settings.py twice during server startup can be fixed with this patch or with runerver --noreload. http://code.djangoproject.com/changeset/15911

However, the import error still persists for test tasks.

+4
source share
1 answer

This is most likely caused because you have both settings.py and the containing package in the import path. Since settings can be imported into different modules (settings and parameters myproject.settings), it can be performed twice.

Just make sure you always use the DJANGO_SETTINGS_MODULE = options instead of DJANGO_SETTINGS_MODULE = myproject.settings or delete the __init__.py file from the directory containing settings.py

Or, better, upgrade to django 1.4

0
source

All Articles