On Dec 8, 2010, at 1:18 PM, Ralph Heinkel wrote: > On Dec 7, 6:06 pm, Michael Bayer <mike...@zzzcomputing.com> 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 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.