Using adaptor objects as query parameters with sqlite3
|Reported by:||mdh||Owned by:||nobody|
|Component:||Database layer (models, ORM)||Version:||1.0|
|Cc:||Triage Stage:||Design decision needed|
|Has patch:||yes||Needs documentation:||no|
|Needs tests:||no||Patch needs improvement:||no|
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.
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.
Change History (4)
comment:1 Changed 8 years ago by
|Patch needs improvement:||unset|
|Triage Stage:||Unreviewed → Design decision needed|