On Wed, Jan 7, 2009 at 7:45 AM, Russell Keith-Magee
<freakboy3...@gmail.com> wrote:
> On Wed, Jan 7, 2009 at 4:19 AM, Ian Kelly <ian.g.ke...@gmail.com> wrote:
>>
>> On Tue, Jan 6, 2009 at 12:14 AM, Ian Kelly <ian.g.ke...@gmail.com> wrote:
>>> On Mon, Jan 5, 2009 at 9:21 AM, Alex Gaynor <alex.gay...@gmail.com> wrote:
>>>> The SQL command not properly ended appears to be the result of an annotate
>>>> call followed by a call to aggregate(). I don't have a clue what causes
>>>> that as I've used Oracle in my life :) .
>>>
>>> I'll take a look at the queries tomorrow and see if I can straighten them
>>> out.
>>
>> The "ORA-00972: identifier is too long" error is caused by the column
>> alias names not being truncated to an acceptable length
>> ("book__publisher__num_awards__min" in this case). The call to
>> perform the truncation is django.db.backends.util.truncate_name(alias,
>> connection.ops.max_name_length()).
>>
>> The "ORA-00923: FROM keyword not found where expected" is caused by
>> one of the column alias names being an unquoted keyword ("number" in
>> this case). Quoting the column alias names with
>> connection.ops.quote_name(alias) will fix it.
>>
>> The "ORA-00933: SQL command not properly ended" errors are caused by
>> queries of the form "SELECT foo FROM (SELECT bar) AS subquery". The
>> "AS" keyword needs to be removed, because Oracle doesn't accept it for
>> subquery aliases.
I've just pushed some updates to Github that should hopefully fix the
problems that have been reported (ORA-00933, ORA-00923 and ORA-00972
and the decimal/datetime conversion problems). If someone with access
to an Oracle test machine can confirm that this has cleaned up the
errors, I'd be much obliged.
There is some potential for further refactoring here, especially with
regards to the decimal/datetime conversion routines. The Oracle
DatabaseOperations.convert_values() function that I added for
aggregate support is an almost perfect subset of the features in the
Oracle Query.convert_values() function.
Refactoring Query.convert_values() into the backend operations would
remove some code duplication, and would also serve to keep all the
data coercion/typecasting code in a common location rather than
spreading some of it into the Query class. However, there are two
things that prevented me from doing this refactor.
Firstly, Query.convert_values() uses a lot of isinstance() calls on
fields, rather than checking the internal type of the field.
Aggregates use the internal type because aggregates aren't actually
fields, but they do return database types. Ian - can you see a problem
with converting the isinstance(field, DecimalField) calls to
field.get_internal_type() == 'DecimalField' etc?
Secondly, contrib.GIS has a convert_values() function that invokes
super(GeoQuery, self).convert_values() in the case of an Oracle
spatial backend. Justin - is there any particular reason to call the
GeoQuery base class specifically, rather than invoking
self.connection.ops.convert_values()? Is GeoQuery likely to have a
base class other than OracleQuery in the Oracle case?
Thanks,
Russ %-)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
