"Ambiguous" numerics with no decimal place
are coerced to int at the connection handler
level. The advantage here is that ints
come back as ints without SQLA type
objects being involved and without needless
conversion to Decimal first.
Unfortunately, some exotic subquery cases
can even see different types between
individual result rows, so the Numeric
handler, when instructed to return Decimal,
can't take full advantage of "native decimal"
mode and must run isinstance() on every value
to check if its Decimal already. Reopen of
[ticket:1840]
ambiguous typing information about numerics
when columns are embedded in subqueries as well
as when ROWNUM is consulted with subqueries, as we
do for limit/offset. We've added these ambiguous
conditions to the cx_oracle "convert to Decimal()"
handler, so that we receive numerics as Decimal
in more cases instead of as floats. These are
then converted, if requested, into Integer
or Float, or otherwise kept as the lossless
Decimal [ticket:1840].
including that use_ansi is set to False automatically,
NVARCHAR2 and NCLOB are not rendered for Unicode,
"native unicode" check doesn't fail, cx_oracle
"native unicode" mode is disabled, VARCHAR() is emitted
with bytes count instead of char count. [ticket:1808]
when limit/offset is used, i.e. the ROWNUM subquery.
However, Oracle can't really handle FOR UPDATE with ORDER BY
or with subqueries, so its still not very usable, but at
least SQLA gets the SQL past the Oracle parser.
[ticket:1815]
DBAPI returns natively the kinds of values we prefer:
- NUMBER values with positive precision + scale convert
to cx_oracle.STRING and then to Decimal. This
allows perfect precision for the Numeric type when
using cx_oracle. [ticket:1759]
- STRING/FIXED_CHAR now convert to unicode natively.
SQLAlchemy's String types then don't need to
apply any kind of conversions.
using character counts, i.e. VARCHAR2(50 CHAR), so that
the column is sized in terms of characters and not bytes.
Column reflection of character types will also use
ALL_TAB_COLUMNS.CHAR_LENGTH instead of
ALL_TAB_COLUMNS.DATA_LENGTH. Both of these behaviors take
effect when the server version is 9 or higher - for
version 8, the old behaviors are used. [ticket:1744]
changes to Enum/SchemaType to re-support adaptation of string types.
This approach can be adapted by "conditional" unicode returning dialects
(i.e. pyodbc and possibly mxodbc) to remove the overhead
of isinstance(value, unicode) calls when the dialect returned type is
of dbapi.UNICODE, dbapi.NVARCHAR, etc.
as the DATE type in Oracle stores full date+time objects,
that's what you'll get. Note that the generic types.Date
type *will* still call value.date() on incoming values,
however. When reflecting a table, the reflected type
will be 'DATE'.
only the DAY TO SECOND interval type so far due to lack
of support in cx_oracle for YEAR TO MONTH. [ticket:1467]
- The Interval type includes a "native" flag which controls
if native INTERVAL types (postgresql + oracle) are selected
if available, or not. "day_precision" and "second_precision"
arguments are also added which propagate as appropriately
to these native types. Related to [ticket:1467].
- DefaultDialect.type_descriptor moves back to being per-dialect.
TypeEngine/TypeDecorator key type impls to the dialect class
+ server_version_info so that the colspecs dict can be modified
per-dialect based on server version.
- Fixed TypeDecorator's incorrect usage of _impl_dict
test user has DBA privs, and all objects can be created /dropped.
- added ORDER BY to oracle column listing
- Oracle all_tables always limits to current user if schema not given.
- views reflect - added documentation + a unit test for this.
- Table(autoload) with no bind produces an error message specific to
the fact that autoload_with should be the first option to try.
on all new connections, which allows all String/Text/etc.
types to skip the need to post-process bytestrings into
unicode (an expensive step due to its volume). Other
dialects which return unicode natively (pg8000, zxjdbc)
also skip unicode post-processing.
- String/Text/Unicode types now skip the unicode() check
on each result column value if the dialect has
detected the DBAPI as returning Python unicode objects
natively. This check is issued on first connect
using "SELECT CAST 'some text' AS VARCHAR(10)" or
equivalent, then checking if the returned object
is a Python unicode. This allows vast performance
increases for native-unicode DBAPIs, including
pysqlite/sqlite3, psycopg2, and pg8000.
to act justlike Oracle's NUMBER type. It is the primary
numeric type returned by table reflection and attempts
to return Decimal()/float/int based on the precision/scale
parameters. [ticket:885]
Mike Bayer