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
6161	Oracle support for queryset-refactor.	jbronn	Malcolm Tredinnick	"I was playing around w/qs-rf branch and successfully merged it w/!GeoDjango (there are a few minor tweaks I had make to `Query`, but otherwise it went well -- I will try and give these diffs to Malcolm later).  Because !GeoDjango supports Oracle, I decided to try it out, but noticed that the `OracleQuerySet` had not been modified to be compatible w/queryset-refactor changes.  

Attached is the patch I used to enable Oracle functionality under the queryset-refactor branch.  Essentially, I added an `OracleQuery` subclass that has `resolve_columns` from the original `OracleQuerySet` and and overrides the `as_sql` method to deal with the peculiarities of limit/offset SQL in Oracle.  The new `OracleQuerySet` subclass just overrides `__init__` to use `OracleQuery`.  There is probably a more elegant way of using qs-rf facilities (e.g., using `get_from_clause` the way `count()` does), but it appears to work well enough to pass all !GeoDjango tests (not confirmed w/Django tests).

Another change (that has been in !GeoDjango for a while) is the modification of the `_format_params` routine in `FormatStylePlaceholderCursor`.  Because !GeoDjango performs spatial queries w/CLOBs (to store WKT geometries), the `setinputsizes` routine needs to be called.  With the patch, `_format_params` looks to see if the parameter has an `oracle_type` method, and if it does it will call `setinputsizes` with the result of `oracle_type`.  For an example of how this is used see the Oracle [browser:django/branches/gis/django/contrib/gis/db/backend/oracle/adaptor.py geometry adaptor class] of !GeoDjango."		closed	Database layer (models, ORM)	other branch		fixed	qs-rf oracle	jbronn@… Erin Kelly	Accepted	1	0	0	0	0	0