On Dec 8, 2010, at 1:18 PM, Ralph Heinkel wrote:
> On Dec 7, 6:06 pm, Michael Bayer <[email protected]> wrote:
>> I hadn't planned any future 0.5 releases, 0.7 is almost ready for betas.
>> What are the incompatibilities you have with 0.6 ?
>
> One example is that Numeric(x,y) in oracle is now translated into
> Python's Decimal in 0.6.x, was 'float' before in 0.5.x. Also somehow
> this conversion gives weird errors, like
Numeric returning Decimal is the documented behavioral contract of Numeric, and
for SQL expression constructs (not strings, see below) does the same thing in
0.5 as well, just inaccurately. If you want Numeric to return floats for SQL
constructs, use the Float type, or specify asdecimal=False on the column.
>
> 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.
> 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 [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
