id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
9633	Using adaptor objects as query parameters with sqlite3	mdh	nobody	"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."		closed	Database layer (models, ORM)	1.0		wontfix			Design decision needed	1	0	0	0	0	0