On Wed, 2009-01-07 at 13:28 -0800, Justin Bronn wrote:
[...]
> I'm -1 on moving conversion operations from the Query class to the
> backend. However, I'd be +1 if Query.convert_values is kept -- even
> if it's just a wrapper around self.connection.ops.convert_values. If
> the conversion functio
On Wed, Jan 7, 2009 at 7:46 AM, Russell Keith-Magee
wrote:
> 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 per
> 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
The solution to the fact that aggregate mutates the query is to have
aggregates() do self._clone() like all the other queryset methods do(not
sure how we missed this).
My guess as to why the odd typecasting occurs is because the `is_computed`
check occurs because the check for DecimalField. When
On Wed, Jan 7, 2009 at 8:55 AM, Karen Tracey wrote:
> On Wed, Jan 7, 2009 at 9:46 AM, Russell Keith-Magee
> wrote:
>>
>> 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 conve
On Wed, Jan 7, 2009 at 9:46 AM, Russell Keith-Magee
wrote:
> 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 mach
On Wed, Jan 7, 2009 at 7:45 AM, Russell Keith-Magee
wrote:
> On Wed, Jan 7, 2009 at 4:19 AM, Ian Kelly wrote:
>>
>> On Tue, Jan 6, 2009 at 12:14 AM, Ian Kelly wrote:
>>> On Mon, Jan 5, 2009 at 9:21 AM, Alex Gaynor wrote:
The SQL command not properly ended appears to be the result of an an
On Wed, Jan 7, 2009 at 4:19 AM, Ian Kelly wrote:
>
> On Tue, Jan 6, 2009 at 12:14 AM, Ian Kelly wrote:
>> On Mon, Jan 5, 2009 at 9:21 AM, Alex Gaynor 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
On Tue, Jan 6, 2009 at 12:14 AM, Ian Kelly wrote:
> On Mon, Jan 5, 2009 at 9:21 AM, Alex Gaynor 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
On Tue, Jan 6, 2009 at 7:52 PM, zvoase wrote:
>
> Just a question - how, if at all, is aggregation going to be supported
> or worked around on custom field types?
Do you have any particular fields in mind? Any custom field deriving
from the basic Django numeric and date/time types shouldn't requ
Well the queries themselves will execute fine, and then you will just back
whatever type your database returned, you'll need to do some coercion
yourself.
Alex
On Tue, Jan 6, 2009 at 4:52 AM, zvoase wrote:
>
> Just a question - how, if at all, is aggregation going to be supported
> or worked ar
Just a question - how, if at all, is aggregation going to be supported
or worked around on custom field types?
On Jan 6, 8:14 am, "Ian Kelly" wrote:
> On Mon, Jan 5, 2009 at 9:21 AM, Alex Gaynor wrote:
> > The one's that are a result of Oracle not returning a Decimal can be solved
> > be insert
On Mon, Jan 5, 2009 at 9:21 AM, Alex Gaynor wrote:
> The one's that are a result of Oracle not returning a Decimal can be solved
> be inserting "..." before and after the number, in placeess of explicitly
> saying Decimal(unless of course this is actually a typecasting issue in
> Django itself, i
On Tue, Jan 6, 2009 at 11:16 AM, Alex Gaynor wrote:
> The datetime issue looks like it's just an issue of porting this logic:
> http://code.djangoproject.com/browser/django/trunk/django/db/backends/oracle/query.py#L72
>
> over to the coerce aggregates function. There's a bit of decimal logic
> a
The datetime issue looks like it's just an issue of porting this logic:
http://code.djangoproject.com/browser/django/trunk/django/db/backends/oracle/query.py#L72
over to the coerce aggregates function. There's a bit of decimal logic
above, but I don't think it's anything different than what we al
On Tue, Jan 6, 2009 at 8:11 AM, Malcolm Tredinnick
wrote:
>
> On Mon, 2009-01-05 at 23:11 +0900, Russell Keith-Magee wrote:
>> Hi all,
>>
>> SQL Aggregations (ticket #3566) are almost ready for trunk!
>>
>> This is a call for final testing.
>
> By the way, I'm pretty sure I accidentally broke dja
On Mon, Jan 5, 2009 at 6:11 PM, Malcolm Tredinnick wrote:
>
> On Mon, 2009-01-05 at 23:11 +0900, Russell Keith-Magee wrote:
> > Hi all,
> >
> > SQL Aggregations (ticket #3566) are almost ready for trunk!
> >
> > This is a call for final testing.
>
> By the way, I'm pretty sure I accidentally brok
On Mon, 2009-01-05 at 23:11 +0900, Russell Keith-Magee wrote:
> Hi all,
>
> SQL Aggregations (ticket #3566) are almost ready for trunk!
>
> This is a call for final testing.
By the way, I'm pretty sure I accidentally broke django.contrib.gis,
both in trunk and, consequently, the branch with th
On Tue, Jan 6, 2009 at 1:21 AM, Alex Gaynor wrote:
> The one's that are a result of Oracle not returning a Decimal can be solved
> be inserting "..." before and after the number, in placeess of explicitly
> saying Decimal(unless of course this is actually a typecasting issue in
> Django itself, i
On Tue, Jan 6, 2009 at 12:51 AM, alex.gay...@gmail.com
wrote:
>
> Karen,
>
> Can you try changing line 230 of django.db.models.sql.query from:
>row = row[:aggregate_start] + tuple(
> to
>row = tuple(row[:aggregate_start]) + tuple(
>
> That should clear up m
The one's that are a result of Oracle not returning a Decimal can be solved
be inserting "..." before and after the number, in placeess of explicitly
saying Decimal(unless of course this is actually a typecasting issue in
Django itself, in which case that should be fixed) this is done a few other
p
On Mon, Jan 5, 2009 at 10:51 AM, alex.gay...@gmail.com <
alex.gay...@gmail.com> wrote:
>
> Karen,
>
> Can you try changing line 230 of django.db.models.sql.query from:
>row = row[:aggregate_start] + tuple(
> to
>row = tuple(row[:aggregate_start]) + tuple(
>
Karen,
Can you try changing line 230 of django.db.models.sql.query from:
row = row[:aggregate_start] + tuple(
to
row = tuple(row[:aggregate_start]) + tuple(
That should clear up most of the errors and seems to be the result of
Oracle returning a list inste
On Mon, Jan 5, 2009 at 9:11 AM, Russell Keith-Magee
wrote:
> [snip]
> In particular, I need feedback on the following:
>
> - Oracle support. I don't have any access to Oracle for testing
> purposes, so I'm relying on the community (esp the Oracle backend
> maintainers) to help me out here.
>
I d
Hi all,
SQL Aggregations (ticket #3566) are almost ready for trunk!
This is a call for final testing. My aim is to have this committed for
the original v1.1 Jan 15 deadline, possibly sooner (depending on the
feedback received). If you want to help out with testing, the code is
available from my
25 matches
Mail list logo
