Unlike sqlite, spatialite requires NAME to be set to run the tests

[Aymeric Augustin]

See ​http://ci.djangoproject.com/job/Django/database=spatialite,python=python2.7/504/console

[Ramiro Morales]

This happens because SpatiaLite backend's DatabaseOperations tries to query and verify the version of the SpatiaLite library in its __init__() method.

This must be done with a SELECT query (hence, a cursor and a connection to the database are needed). For this, it creates disposable connection+cursor well before DatabaseWrapper creates the main, 'official' connection (remember that DatabaseOperations instance self.ops is instantiated in DatabaseWrapper.__init__()). This works because, even when the interface is a SELECT SQL query, no actual database is needed to query for the SpatiaLite library version.

All this doesn't cause problems with a normal project/application setup because there settings.DATABASES['whatever']['NAME'] are expected to have valid values.

Problem occurs with the test database setup with no settings.DATABASES['whatever']['NAME'] because in that scenario, when DatabaseWrapper.__init__() gets executed, the test DB creation machinery from django.contrib.gis.db.backends.spatialite.creation hasn't had a chance to run yet and so the database name hasn't been set to the fallback ':memory:' value.

The attached patch moves the SpatiaLite version querying/checking tasks to a separate internal method and inserts a call to it right after the connection to the database and SpatiaLite initialization have been performed.

[Claude Paroz]

Looks good

[Julien Phalip]

I've updated the patch to avoid a problem with the 'spatial_version' variable not being set at the right time.

[Julien Phalip <jphalip@…>]

In [675431dfaaa7fc9fbd89be2602332287489ee04f]:

Fixed #17278 -- Enabled the spatialite GIS tests to run without having to specify a database name in the settings. Thanks to Aymeric for the report and to Ramiro for the initial patch.