Hi, Sorry about the delay in writing this -- it was in my mind, but I forgot
to let it out...
On Sunday 23 September 2012, Anssi Kääriäinen wrote:
> On 22 syys, 23:34, Shai Berger <s...@platonix.com> wrote:
> >
> > [...] I will also include the extra setting in
> > the "options" dictionary (choosing if expressions should be treated as
> > decimals or floats). I think this is then an added feature, and needs to
> > get in before the feature freeze. Otherwise, just fixing the performance
> > can be treated as a bug in be included later. Is this guess correct?
>
> There isn't much time to do feature additions. It is possible to get
> the feature into 1.5, but you should not expect it to happen. As for
> the feature itself, I am not yet sure if it is a good idea or not. The
> basic problem is granularity: wouldn't you want to do this per query,
> or even per expression basis?
>
No, I don't; the issue is cross-database compatibility. We have raw SQL
statements calculating some expressions, and then use the returned values in
calculations in Python -- adding and muliplying them with floats. This worked
fine with MySql and the 3rd-party SQL Server backends, but blew up on Oracle
because Decimals and floats don't mix very well:
>>> from decimal import Decimal as D
>>> D(1) + 1.0
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'Decimal' and 'float'
>>> 1.0 + D(1)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'float' and 'Decimal'
I could, of course, solve it on a query-by-query basis, adding a cast to float
that is a nop on other backends. That seems a little backward to me, and an
unfair requirements of pluggable apps.
Similarly, any per-query or per-expression API would be added only when using
Oracle, and at best be a NO-OP on other engines -- which means it would only
be added by Oracle users, with the same consequences.
It seems much better to me to make it possible to run Oracle in a mode that
makes expressions in raw sql have semantics that is compatible with other
backends.
(would filing a bug with the above arguments make it more likely to include the
feature in 1.5?)
Thanks,
Shai.
--
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.
