On May 6, 2010, at 12:11 PM, Kent Bower wrote:
> The following has changed since 0.5.8 in 0.6.0. I believe this is already
> known or by design from reading docs and another post but want to point out.
>
> If you specify a column such as this:
> Column("saleprice", Numeric, nullable=False)
> you get a 'numeric' type in PostgreSQL, which supports any type of number,
> integer or decimal.
>
> On the other hand, in Oracle (at least 10g), you get 'NUMBER(38)' which is
> *only* integer.
>
> (If I specify a precision, I don't have this problem, but there may be
> reasons to not want to specify precision.)
> So my questions are:
>
> Are we sure we are ok with this inconsistency (it makes it more difficult to
> write software that behaves identically regardless of database)?
> Is there a replacement type that acts the same regardless of the engine?
so, "Numeric" translates as "NUMERIC" in DDL. For Oracle, their "numeric" and
"integer" types are both called "NUMBER", which has many synonyms including
NUMERIC, DECIMAL, INTEGER, etc. What determines int/decimal on oracle is the
precision and scale you send along. There's a full list of those here:
http://ss64.com/ora/syntax-datatypes.html . When scale is 0, you
essentially get get INT:
SQL> create table foo(d1 NUMERIC, d2 NUMBER, d3 NUMERIC(10, 3));
SQL> insert into foo values (3.56, 3.56, 3.56);
SQL> select * from foo;
D1 D2 D3
---------- ---------- ----------
4 3.56 3.56
the solution is therefore *always* have precision and scale specified when
using Numeric. For DBAPIs where we can only get back floating point values,
we even use the precision/scale ourselves when converting to decimal.Decimal,
so these values are essential for correct functioning of DDL and result
processing.
The behavior of Numeric is definitely the most consistent and accurate it's
ever been in 0.6, but also it is no longer doing any "guessing" like it did in
previous versions.
>
> Thanks in advance.
>
>
> --
> 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.
