Support for the Oracle database.
The following dialect/DBAPI options are available. Please refer to individual DBAPI sections for connect information.
The dialect supports several create_engine()
arguments
which affect the behavior of the dialect regardless of driver in use.
use_ansi
- Use ANSI JOIN constructs (see the section on Oracle 8).
Defaults to True
. If False
, Oracle-8 compatible constructs are used
for joins.optimize_limits
- defaults to False
. see the section on
LIMIT/OFFSET.use_binds_for_limits
- defaults to True
. see the section on
LIMIT/OFFSET.SQLAlchemy Table objects which include integer primary keys are usually assumed to have “autoincrementing” behavior, meaning they can generate their own primary key values upon INSERT. Since Oracle has no “autoincrement” feature, SQLAlchemy relies upon sequences to produce these values. With the Oracle dialect, a sequence must always be explicitly specified to enable autoincrement. This is divergent with the majority of documentation examples which assume the usage of an autoincrement-capable database. To specify sequences, use the sqlalchemy.schema.Sequence object which is passed to a Column construct:
t = Table('mytable', metadata,
Column('id', Integer, Sequence('id_seq'), primary_key=True),
Column(...), ...
)
This step is also required when using table reflection, i.e. autoload=True:
t = Table('mytable', metadata,
Column('id', Integer, Sequence('id_seq'), primary_key=True),
autoload=True
)
In Oracle, the data dictionary represents all case insensitive identifier names using UPPERCASE text. SQLAlchemy on the other hand considers an all-lower case identifier name to be case insensitive. The Oracle dialect converts all case insensitive identifiers to and from those two formats during schema level communication, such as reflection of tables and indexes. Using an UPPERCASE name on the SQLAlchemy side indicates a case sensitive identifier, and SQLAlchemy will quote the name - this will cause mismatches against data dictionary data received from Oracle, so unless identifier names have been truly created as case sensitive (i.e. using quoted names), all lowercase names should be used on the SQLAlchemy side.
Oracle has no support for the LIMIT or OFFSET keywords. SQLAlchemy uses a wrapped subquery approach in conjunction with ROWNUM. The exact methodology is taken from http://www.oracle.com/technology/oramag/oracle/06-sep/o56asktom.html .
There are two options which affect its behavior:
optimize_limits=True
to create_engine()
.use_binds_for_limits=False
to create_engine()
.Some users have reported better performance when the entirely different approach of a window query is used, i.e. ROW_NUMBER() OVER (ORDER BY), to provide LIMIT/OFFSET (note that the majority of users don’t observe this). To suit this case the method used for LIMIT/OFFSET can be replaced entirely. See the recipe at http://www.sqlalchemy.org/trac/wiki/UsageRecipes/WindowFunctionsByDefault which installs a select compiler that overrides the generation of limit/offset with a window function.
The Oracle database supports a limited form of RETURNING, in order to retrieve result sets of matched rows from INSERT, UPDATE and DELETE statements. Oracle’s RETURNING..INTO syntax only supports one row being returned, as it relies upon OUT parameters in order to function. In addition, supported DBAPIs have further limitations (see RETURNING Support).
SQLAlchemy’s “implicit returning” feature, which employs RETURNING within an
INSERT and sometimes an UPDATE statement in order to fetch newly generated
primary key values and other SQL defaults and expressions, is normally enabled
on the Oracle backend. By default, “implicit returning” typically only
fetches the value of a single nextval(some_seq)
expression embedded into
an INSERT in order to increment a sequence within an INSERT statement and get
the value back at the same time. To disable this feature across the board,
specify implicit_returning=False
to create_engine()
:
engine = create_engine("oracle://scott:tiger@dsn",
implicit_returning=False)
Implicit returning can also be disabled on a table-by-table basis as a table option:
# Core Table
my_table = Table("my_table", metadata, ..., implicit_returning=False)
# declarative
class MyClass(Base):
__tablename__ = 'my_table'
__table_args__ = {"implicit_returning": False}
See also
RETURNING Support - additional cx_oracle-specific restrictions on implicit returning.
Oracle doesn’t have native ON UPDATE CASCADE functionality. A trigger based solution is available at http://asktom.oracle.com/tkyte/update_cascade/index.html .
When using the SQLAlchemy ORM, the ORM has limited ability to manually issue cascading updates - specify ForeignKey objects using the “deferrable=True, initially=’deferred’” keyword arguments, and specify “passive_updates=False” on each relationship().
When Oracle 8 is detected, the dialect internally configures itself to the following behaviors:
Unicode
is used - VARCHAR2 and CLOB are
issued instead. This because these types don’t seem to work correctly on
Oracle 8 even though they are available. The
NVARCHAR
and
NCLOB
types will always generate
NVARCHAR2 and NCLOB.When using reflection with Table objects, the dialect can optionally search
for tables indicated by synonyms, either in local or remote schemas or
accessed over DBLINK, by passing the flag oracle_resolve_synonyms=True
as
a keyword argument to the Table
construct:
some_table = Table('some_table', autoload=True,
autoload_with=some_engine,
oracle_resolve_synonyms=True)
When this flag is set, the given name (such as some_table
above) will
be searched not just in the ALL_TABLES
view, but also within the
ALL_SYNONYMS
view to see if this name is actually a synonym to another
name. If the synonym is located and refers to a DBLINK, the oracle dialect
knows how to locate the table’s information using DBLINK syntax(e.g.
@dblink
).
oracle_resolve_synonyms
is accepted wherever reflection arguments are
accepted, including methods such as MetaData.reflect()
and
Inspector.get_columns()
.
If synonyms are not in use, this flag should be left disabled.
The Inspector.get_table_names()
and
Inspector.get_temp_table_names()
methods each return a list of table names for the current engine. These methods
are also part of the reflection which occurs within an operation such as
MetaData.reflect()
. By default, these operations exclude the SYSTEM
and SYSAUX
tablespaces from the operation. In order to change this, the
default list of tablespaces excluded can be changed at the engine level using
the exclude_tablespaces
parameter:
# exclude SYSAUX and SOME_TABLESPACE, but not SYSTEM
e = create_engine(
"oracle://scott:tiger@xe",
exclude_tablespaces=["SYSAUX", "SOME_TABLESPACE"])
New in version 1.1.
Oracle has no datatype known as DATETIME
, it instead has only DATE
,
which can actually store a date and time value. For this reason, the Oracle
dialect provides a type oracle.DATE
which is a subclass of
DateTime
. This type has no special behavior, and is only
present as a “marker” for this type; additionally, when a database column
is reflected and the type is reported as DATE
, the time-supporting
oracle.DATE
type is used.
Changed in version 0.9.4: Added oracle.DATE
to subclass
DateTime
. This is a change as previous versions
would reflect a DATE
column as types.DATE
, which subclasses
Date
. The only significance here is for schemes that are
examining the type of column for use in special Python translations or
for migrating schemas to other database backends.
The CREATE TABLE phrase supports the following options with Oracle
in conjunction with the Table
construct:
ON COMMIT
:
Table(
"some_table", metadata, ...,
prefixes=['GLOBAL TEMPORARY'], oracle_on_commit='PRESERVE ROWS')
New in version 1.0.0.
COMPRESS
:
Table('mytable', metadata, Column('data', String(32)),
oracle_compress=True)
Table('mytable', metadata, Column('data', String(32)),
oracle_compress=6)
The ``oracle_compress`` parameter accepts either an integer compression
level, or ``True`` to use the default compression level.
New in version 1.0.0.
You can specify the oracle_bitmap
parameter to create a bitmap index
instead of a B-tree index:
Index('my_index', my_table.c.data, oracle_bitmap=True)
Bitmap indexes cannot be unique and cannot be compressed. SQLAlchemy will not check for such limitations, only the database will.
New in version 1.0.0.
Oracle has a more efficient storage mode for indexes containing lots of
repeated values. Use the oracle_compress
parameter to turn on key c
ompression:
Index('my_index', my_table.c.data, oracle_compress=True)
Index('my_index', my_table.c.data1, my_table.c.data2, unique=True,
oracle_compress=1)
The oracle_compress
parameter accepts either an integer specifying the
number of prefix columns to compress, or True
to use the default (all
columns for non-unique indexes, all but the last column for unique indexes).
New in version 1.0.0.
As with all SQLAlchemy dialects, all UPPERCASE types that are known to be
valid with Oracle are importable from the top level dialect, whether
they originate from sqlalchemy.types
or from the local dialect:
from sqlalchemy.dialects.oracle import \
BFILE, BLOB, CHAR, CLOB, DATE, \
DOUBLE_PRECISION, FLOAT, INTERVAL, LONG, NCLOB, \
NUMBER, NVARCHAR, NVARCHAR2, RAW, TIMESTAMP, VARCHAR, \
VARCHAR2
Types which are specific to Oracle, or have Oracle-specific construction arguments, are as follows:
sqlalchemy.dialects.oracle.
BFILE
(length=None)¶Bases: sqlalchemy.types.LargeBinary
__init__
(length=None)¶__init__()
method of LargeBinary
Construct a LargeBinary type.
Parameters: | length¶ – optional, a length for the column for use in DDL statements, for those binary types that accept a length, such as the MySQL BLOB type. |
---|
sqlalchemy.dialects.oracle.
DATE
(timezone=False)¶Bases: sqlalchemy.types.DateTime
Provide the oracle DATE type.
This type has no special Python behavior, except that it subclasses
types.DateTime
; this is to suit the fact that the Oracle
DATE
type supports a time value.
New in version 0.9.4.
__init__
(timezone=False)¶__init__()
method of DateTime
Construct a new DateTime
.
Parameters: | timezone¶ – boolean. Indicates that the datetime type should
enable timezone support, if available on the
base date/time-holding type only. It is recommended
to make use of the TIMESTAMP datatype directly when
using this flag, as some databases include separate generic
date/time-holding types distinct from the timezone-capable
TIMESTAMP datatype, such as Oracle. |
---|
sqlalchemy.dialects.oracle.
DOUBLE_PRECISION
(precision=None, scale=None, asdecimal=None)¶Bases: sqlalchemy.types.Numeric
sqlalchemy.dialects.oracle.
INTERVAL
(day_precision=None, second_precision=None)¶Bases: sqlalchemy.types.TypeEngine
__init__
(day_precision=None, second_precision=None)¶Construct an INTERVAL.
Note that only DAY TO SECOND intervals are currently supported. This is due to a lack of support for YEAR TO MONTH intervals within available DBAPIs (cx_oracle and zxjdbc).
Parameters: |
---|
sqlalchemy.dialects.oracle.
NCLOB
(length=None, collation=None, convert_unicode=False, unicode_error=None, _warn_on_bytestring=False)¶Bases: sqlalchemy.types.Text
__init__
(length=None, collation=None, convert_unicode=False, unicode_error=None, _warn_on_bytestring=False)¶__init__()
method of String
Create a string-holding type.
Parameters: |
|
---|
sqlalchemy.dialects.oracle.
NUMBER
(precision=None, scale=None, asdecimal=None)¶sqlalchemy.dialects.oracle.
LONG
(length=None, collation=None, convert_unicode=False, unicode_error=None, _warn_on_bytestring=False)¶Bases: sqlalchemy.types.Text
__init__
(length=None, collation=None, convert_unicode=False, unicode_error=None, _warn_on_bytestring=False)¶__init__()
method of String
Create a string-holding type.
Parameters: |
|
---|
sqlalchemy.dialects.oracle.
RAW
(length=None)¶Bases: sqlalchemy.types._Binary
Support for the Oracle database via the cx-Oracle driver.
Documentation and download information (if applicable) for cx-Oracle is available at: http://cx-oracle.sourceforge.net/
When connecting with dbname
present, the host, port, and dbname tokens are
converted to a TNS name using
the cx_oracle makedsn()
function. Otherwise, the host token is taken
directly as a TNS name.
Additional arguments which may be specified either as query string arguments
on the URL, or as keyword arguments to create_engine()
are:
allow_twophase
- enable two-phase transactions. Defaults to True
.
arraysize
- set the cx_oracle.arraysize value on cursors, defaulted
to 50. This setting is significant with cx_Oracle as the contents of LOB
objects are only readable within a “live” row (e.g. within a batch of
50 rows).
auto_convert_lobs
- defaults to True; See LOB Objects.
auto_setinputsizes
- the cx_oracle.setinputsizes() call is issued for
all bind parameters. This is required for LOB datatypes but can be
disabled to reduce overhead. Defaults to True
. Specific types
can be excluded from this process using the exclude_setinputsizes
parameter.
coerce_to_unicode
- see Unicode for detail.
coerce_to_decimal
- see Precision Numerics for detail.
exclude_setinputsizes
- a tuple or list of string DBAPI type names to
be excluded from the “auto setinputsizes” feature. The type names here
must match DBAPI types that are found in the “cx_Oracle” module namespace,
such as cx_Oracle.UNICODE, cx_Oracle.NCLOB, etc. Defaults to
(STRING, UNICODE)
.
New in version 0.8: specific DBAPI types can be excluded from the auto_setinputsizes feature via the exclude_setinputsizes attribute.
mode
- This is given the string value of SYSDBA or SYSOPER, or
alternatively an integer value. This value is only available as a URL query
string argument.
threaded
- enable multithreaded access to cx_oracle connections.
Defaults to True
. Note that this is the opposite default of the
cx_Oracle DBAPI itself.
service_name
- An option to use connection string (DSN) with
SERVICE_NAME
instead of SID
. It can’t be passed when a database
part is given.
E.g. oracle+cx_oracle://scott:tiger@host:1521/?service_name=hr
is a valid url. This value is only available as a URL query string argument.
New in version 1.0.0.
The cx_Oracle DBAPI as of version 5 fully supports unicode, and has the ability to return string results as Python unicode objects natively.
When used in Python 3, cx_Oracle returns all strings as Python unicode objects
(that is, plain str
in Python 3). In Python 2, it will return as Python
unicode those column values that are of type NVARCHAR
or NCLOB
. For
column values that are of type VARCHAR
or other non-unicode string types,
it will return values as Python strings (e.g. bytestrings).
The cx_Oracle SQLAlchemy dialect presents two different options for the use
case of returning VARCHAR
column values as Python unicode objects under
Python 2:
Unicode
type or String
type with
convert_unicode=True
is explicitly associated with the result column.
This is the case for any ORM or Core query or SQL expression as well as for
a text()
construct that specifies output column types, so in the vast
majority of cases this is not an issue. However, when sending a completely
raw string to Connection.execute()
, this typing information isn’t
present, unless the string is handled within a text()
construct that
adds typing information.As of version 0.9.2 of SQLAlchemy, the default approach is to use SQLAlchemy’s typing system. This keeps cx_Oracle’s expensive Python 2 approach disabled unless the user explicitly wants it. Under Python 3, SQLAlchemy detects that cx_Oracle is returning unicode objects natively and cx_Oracle’s system is used.
To re-enable cx_Oracle’s output type handler under Python 2, the
coerce_to_unicode=True
flag (new in 0.9.4) can be passed to
create_engine()
:
engine = create_engine("oracle+cx_oracle://dsn", coerce_to_unicode=True)
Alternatively, to run a pure string SQL statement and get VARCHAR
results
as Python unicode under Python 2 without using cx_Oracle’s native handlers,
the text()
feature can be used:
from sqlalchemy import text, Unicode
result = conn.execute(
text("select username from user").columns(username=Unicode))
Changed in version 0.9.2: cx_Oracle’s outputtypehandlers are no longer used for unicode results of non-unicode datatypes in Python 2, after they were identified as a major performance bottleneck. SQLAlchemy’s own unicode facilities are used instead.
New in version 0.9.4: Added the coerce_to_unicode
flag, to re-enable
cx_Oracle’s outputtypehandler and revert to pre-0.9.2 behavior.
The cx_oracle DBAPI supports a limited subset of Oracle’s already limited RETURNING support. Typically, results can only be guaranteed for at most one column being returned; this is the typical case when SQLAlchemy uses RETURNING to get just the value of a primary-key-associated sequence value. Additional column expressions will cause problems in a non-determinative way, due to cx_oracle’s lack of support for the OCI_DATA_AT_EXEC API which is required for more complex RETURNING scenarios.
For this reason, stability may be enhanced by disabling RETURNING support completely; SQLAlchemy otherwise will use RETURNING to fetch newly sequence-generated primary keys. As illustrated in RETURNING Support:
engine = create_engine("oracle://scott:tiger@dsn",
implicit_returning=False)
See also
http://docs.oracle.com/cd/B10501_01/appdev.920/a96584/oci05bnd.htm#420693 - OCI documentation for RETURNING
http://sourceforge.net/mailarchive/message.php?msg_id=31338136 - cx_oracle developer commentary
cx_oracle returns oracle LOBs using the cx_oracle.LOB object. SQLAlchemy converts these to strings so that the interface of the Binary type is consistent with that of other backends, and so that the linkage to a live cursor is not needed in scenarios like result.fetchmany() and result.fetchall(). This means that by default, LOB objects are fully fetched unconditionally by SQLAlchemy, and the linkage to a live cursor is broken.
To disable this processing, pass auto_convert_lobs=False
to
create_engine()
.
Two Phase transactions are implemented using XA transactions, and are known to work in a rudimental fashion with recent versions of cx_Oracle as of SQLAlchemy 0.8.0b2, 0.7.10. However, the mechanism is not yet considered to be robust and should still be regarded as experimental.
In particular, the cx_Oracle DBAPI as recently as 5.1.2 has a bug regarding
two phase which prevents
a particular DBAPI connection from being consistently usable in both
prepared transactions as well as traditional DBAPI usage patterns; therefore
once a particular connection is used via Connection.begin_prepared()
,
all subsequent usages of the underlying DBAPI connection must be within
the context of prepared transactions.
The default behavior of Engine
is to maintain a pool of DBAPI
connections. Therefore, due to the above glitch, a DBAPI connection that has
been used in a two-phase operation, and is then returned to the pool, will
not be usable in a non-two-phase context. To avoid this situation,
the application can make one of several choices:
NullPool
Engine
in use is only used
for two-phase operations. A Engine
bound to an ORM
Session
which includes twophase=True
will consistently
use the two-phase transaction style.Connection.detach()
method.Changed in version 0.8.0b2,0.7.10: Support for cx_oracle prepared transactions has been implemented and tested.
The SQLAlchemy dialect goes through a lot of steps to ensure
that decimal numbers are sent and received with full accuracy.
An “outputtypehandler” callable is associated with each
cx_oracle connection object which detects numeric types and
receives them as string values, instead of receiving a Python
float
directly, which is then passed to the Python
Decimal
constructor. The Numeric
and
Float
types under the cx_oracle dialect are aware of
this behavior, and will coerce the Decimal
to float
if
the asdecimal
flag is False
(default on Float
,
optional on Numeric
).
Because the handler coerces to Decimal
in all cases first,
the feature can detract significantly from performance.
If precision numerics aren’t required, the decimal handling
can be disabled by passing the flag coerce_to_decimal=False
to create_engine()
:
engine = create_engine("oracle+cx_oracle://dsn", coerce_to_decimal=False)
New in version 0.7.6: Add the coerce_to_decimal
flag.
Another alternative to performance is to use the
cdecimal library;
see Numeric
for additional notes.
The handler attempts to use the “precision” and “scale”
attributes of the result set column to best determine if
subsequent incoming values should be received as Decimal
as
opposed to int (in which case no processing is added). There are
several scenarios where OCI does not provide unambiguous data
as to the numeric type, including some situations where
individual rows may return a combination of floating point and
integer values. Certain values for “precision” and “scale” have
been observed to determine this scenario. When it occurs, the
outputtypehandler receives as string and then passes off to a
processing function which detects, for each returned value, if a
decimal point is present, and if so converts to Decimal
,
otherwise to int. The intention is that simple int-based
statements like “SELECT my_seq.nextval() FROM DUAL” continue to
return ints and not Decimal
objects, and that any kind of
floating point value is received as a string so that there is no
floating point loss of precision.
The “decimal point is present” logic itself is also sensitive to locale. Under OCI, this is controlled by the NLS_LANG environment variable. Upon first connection, the dialect runs a test to determine the current “decimal” character, which can be a comma ”,” for European locales. From that point forward the outputtypehandler uses that character to represent a decimal point. Note that cx_oracle 5.0.3 or greater is required when dealing with numerics with locale settings that don’t use a period ”.” as the decimal character.
Changed in version 0.6.6: The outputtypehandler supports the case where the locale uses a comma ”,” character to represent a decimal point.
Support for the Oracle database via the zxJDBC for Jython driver.
Note
Jython is not supported by current versions of SQLAlchemy. The zxjdbc dialect should be considered as experimental.
Drivers for this database are available at: http://www.oracle.com/technetwork/database/features/jdbc/index-091264.html