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.
source share