On Dec 8, 2010, at 2:02 PM, Michael Bayer wrote:
>
>
>>
>> engine.execute("select IEP from mytable where name='IP3'").fetchone()
>
> So here we're using text. In order for Numeric to be returned without loss
> in accuracy, cx_oracle is configured now to return Decimal objects for
> non-float numerics, the same way that psycopg2 and others do it. Converting
> from floating point is not an option since there is an inherent loss of
> information in an fp.
>
> In the case of a plain textual statement, Oracle unfortunately doesn't give
> us accurate enough information to detect NUMBER with no p, s which is what
> implies float (see http://ss64.com/ora/syntax-datatypes.html), and many hours
> have gone into tweaking the numeric converters so that the behavior is as
> intuitive as it can possibly be, while still returning fully accurate
> numerics for all statements that request them.
>
> So if you're running textual statements and truly need an fp, not a Decimal,
> you'd change this to read:
>
> engine.execute(text("select IEP from mytable where name='IP3'",
> typemap={'IEP':Float}))
>
> We haven't received any requests specifically regarding floats being
> delivered as specified with textual SQL statements, even though we have a
> handful of Oracle users that report issues as they come across them. Since
> you are now reporting this here, I will do some experimentation to see if
> "float" can't be better detected as most of the work has gone into protecting
> ints from not going to Decimal when its not wanted.
So just added some tests to tip for this, the most recent Oracle numeric
handling does treat basic fps from Oracle correctly, if the datatype is FLOAT,
which is actually NUMBER with no p, s, it does send back the fp straight from
Oracle. So if you're looking for fps make sure the datatype is actually a
FLOAT otherwise you want to CAST it as in "SELECT CAST(IEP AS FLOAT) FROM
mytable".
>
>
>> decimal.InvalidOperation: Invalid literal for Decimal: '7,01'
>
>> It has a comma instead of a dot!
>> I have NLS_LANG="GERMAN_GERMANY.AL32UTF8 set which we need for other
>> reasons.
>
> This issue is http://www.sqlalchemy.org/trac/ticket/1953, and is fixed,
> available in 0.6.6 which will be released soon, or get it right now:
> http://hg.sqlalchemy.org/sqlalchemy/archive/rel_0_6.tar.gz . It's critical
> that issues like these get reported to me via trac, fortunately someone else
> has already done so in this case and your bug is fixed.
>
>> Another difference to 0.5.x is that rolling back a fresh engine (or an
>> engine that has been rolled back) raises Exceptions. Before this just
>> silently did nothing. In our WebFramework we sometimes rollback the
>> engines at the far top of the http request just to be sure nothing is
>> floating around.
>
> This is also a bug, and it is also critical that regressions like this get
> reported to me via trac.
>
> Ticket 1998 has been created http://www.sqlalchemy.org/trac/ticket/1998 and
> is now fixed. This is also in the tar.gz at
> http://hg.sqlalchemy.org/sqlalchemy/archive/rel_0_6.tar.gz
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "sqlalchemy" group.
> To post to this group, send email to sqlalch...@googlegroups.com.
> To unsubscribe from this group, send email to
> sqlalchemy+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sqlalchemy?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
