Using adaptor objects as query parameters with sqlite3

[mdh]

And now for my final stumbling block within the Django core on the road to using GeoDjango with SQLite:

It is handy to be able to pass an adaptor object as a query parameter that will ultimately end up in the hands of cursor.execute(), which can convert the adaptor to a string to insert into the SQL. This is explicitly supported in (at least) the postgresql back-end, where it’s handled by [source:django/trunk/django/db/backends/postgresql/base.py UnicodeCursorWrapper.format_params()]. GeoDjango currently takes advantage of this when it uses [source:django/trunk/django/contrib/gis/db/backend/postgis/adaptor.py PostGISAdaptor] to wrap, well, pretty much any geospatial entity en route to PostGIS.

The sqlite3 back-end could easily support something similar, but it doesn’t: if you try the corresponding trick with SQLite, you get to enjoy “InterfaceError: Error binding parameter 0 - probably unsupported type.” There may be a completely different way to address the underlying problem, which I’d certainly be very open to hearing about, but I’m personally inclined towards doing things in the corresponding ways for each back-end as much as possible, so this is the approach I’ve taken for now..

I’ve attached a fairly simple patch that takes what is clearly one of many possible similar approaches to achieving the corresponding thing for sqlite3, as well as quick test to see if your favorite back-end supports query parameter adaptors.

[mdh]

A first patch to support adaptor objects as query parameters with sqlite3

[jbronn]

clean up of initial patch

[jbronn]

This patch was not necessary for SpatiaLite support. Just had to add a __conform__ method to the [browser:django/trunk/django/contrib/gis/db/backend/spatialite/adaptor.py SpatiaLite adaptor].