6

Django: 1.3; PyCharm: 1.5.3

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

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

Without getting too much into the code that caused this error, I found that every time I run a unit test, Django imported the settings, created a test database and destroyed the database immediately, and then created the test database again for the tests that ultimately would throw 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 a Terminal shell, the same process was repeated and the same errors were thrown.

I checked my settings file but couldn't find out why it is prompting itself to be imported twice and why the test database was created twice. The required init_spatialite-2.*.sql for creating Spatialite database is also on the project path.

Any advice would be highly appreciated!

Update: I was informed by JetBrains that the twice-importing of settings.py during runserver can be fixed with this patch or by runserver --noreload. http://code.djangoproject.com/changeset/15911

However, the import error still persisted for test tasks.

Li Xiong
  • 718
  • 1
  • 5
  • 8
  • This didn't cause me any problems with testing other modules in the application that do not require the use of Geometry columns that GEOS supports/creates. So I have a strong suspicion that the Geometry fields can't be saved because of this database error, but I couldn't prove or test it :(. – Li Xiong Jul 13 '11 at 01:04
  • This is (was?) a known issue, google: django settings imported twice. I think since Django 1.4 double loading doesn't happen anymore. – n3storm Mar 15 '13 at 11:29
  • I've noticed that settings.py does load twice with 1.4 and later. – jarmod Mar 16 '13 at 20:32

1 Answers1

2

This is caused most probably because you have both the settings.py and containing package on the import path. Because the settings can be imported under different modules (settings and myproject.settings) it can get executed two times.

Just make sure you always use DJANGO_SETTINGS_MODULE=settings instead of DJANGO_SETTINGS_MODULE=myproject.settings or remove the __init__.py file from the directory that contains settings.py

Or, better, upgrade to django 1.4

ionelmc
  • 720
  • 2
  • 10
  • 29