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/technetwork/issue-archive/2006/06-sep/o56asktom-086197.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 Oracle dialect can return information about foreign key, unique, and CHECK constraints, as well as indexes on tables.
Raw information regarding these constraints can be acquired using
Inspector.get_foreign_keys()
, Inspector.get_unique_constraints()
,
Inspector.get_check_constraints()
, and Inspector.get_indexes()
.
Changed in version 1.2: The Oracle dialect can now reflect UNIQUE and CHECK constraints.
When using reflection at the Table
level, the Table
will also include these constraints.
Note the following caveats:
When using the Inspector.get_check_constraints()
method, Oracle
builds a special “IS NOT NULL” constraint for columns that specify
“NOT NULL”. This constraint is not returned by default; to include
the “IS NOT NULL” constraints, pass the flag include_all=True
:
from sqlalchemy import create_engine, inspect
engine = create_engine("oracle+cx_oracle://s:t@dsn")
inspector = inspect(engine)
all_check_constraints = inspector.get_check_constraints(
"some_table", include_all=True)
in most cases, when reflecting a Table
, a UNIQUE constraint will
not be available as a UniqueConstraint
object, as Oracle
mirrors unique constraints with a UNIQUE index in most cases (the exception
seems to be when two or more unique constraints represent the same columns);
the Table
will instead represent these using Index
with the unique=True
flag set.
Oracle creates an implicit index for the primary key of a table; this index is excluded from all index results.
the list of columns reflected for an index will not include column names that start with SYS_NC.
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, asdecimal=False, decimal_return_scale=None, **kwargs)¶Bases: sqlalchemy.types.Float
__init__
(precision=None, asdecimal=False, decimal_return_scale=None, **kwargs)¶__init__()
method of Float
Construct a Float.
Parameters: |
|
---|
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)¶Bases: sqlalchemy.types.Numeric
, sqlalchemy.types.Integer
__init__
(precision=None, scale=None, asdecimal=None)¶Construct a Numeric.
Parameters: |
|
---|
When using the Numeric
type, care should be taken to ensure
that the asdecimal setting is apppropriate for the DBAPI in use -
when Numeric applies a conversion from Decimal->float or float->
Decimal, this conversion incurs an additional performance overhead
for all result columns received.
DBAPIs that return Decimal natively (e.g. psycopg2) will have
better accuracy and higher performance with a setting of True
,
as the native translation to Decimal reduces the amount of floating-
point issues at play, and the Numeric type itself doesn’t need
to apply any further conversions. However, another DBAPI which
returns floats natively will incur an additional conversion
overhead, and is still subject to floating point data loss - in
which case asdecimal=False
will at least remove the extra
conversion overhead.
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: |
|
---|
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:
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.
coerce_to_unicode
- see Unicode for detail.
coerce_to_decimal
- see Precision Numerics for detail.
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 several different options for the use
case of receiving VARCHAR
column values as Python unicode objects under
Python 2:
When using Core expression objects as well as the ORM, SQLAlchemy’s
unicode-decoding services are available, which are established by
using either the Unicode
datatype or by using the
String
datatype with String.convert_unicode
set
to True.
When using raw SQL strings, typing behavior can be added for unicode
conversion using the text()
construct:
from sqlalchemy import text, Unicode
result = conn.execute(
text("select username from user").columns(username=Unicode))
Otherwise, when using raw SQL strings sent directly to an .execute()
method without any Core typing behavior added, the flag
coerce_to_unicode=True
flag can be passed to create_engine()
which will add an unconditional unicode processor to cx_Oracle for all
string values:
engine = create_engine("oracle+cx_oracle://dsn", coerce_to_unicode=True)
The above approach will add significant latency to result-set fetches of plain string values.
As of SQLAlchemy 1.2.2, the cx_Oracle dialect unconditionally calls
setinputsizes()
for bound values that are passed as Python unicode objects.
In Python 3, all string values are Unicode; for cx_Oracle, this corresponds to
cx_Oracle.NCHAR
being passed to setinputsizes()
for that parameter.
In some edge cases, such as passing format specifiers for
the trunc()
function, Oracle does not accept these as NCHAR:
from sqlalchemy import func
conn.execute(
func.trunc(func.sysdate(), 'dd')
)
In these cases, an error as follows may be raised:
ORA-01899: bad precision specifier
When this error is encountered, it may be necessary to pass the string value with an explicit non-unicode type:
from sqlalchemy import func
from sqlalchemy import literal
from sqlalchemy import String
conn.execute(
func.trunc(func.sysdate(), literal('dd', String))
)
For full control over this setinputsizes()
behavior, see the section
Fine grained control over cx_Oracle data binding and performance with setinputsizes
The cx_Oracle DBAPI has a deep and fundamental reliance upon the usage of the
DBAPI setinputsizes()
call. The purpose of this call is to establish the
datatypes that are bound to a SQL statement for Python values being passed as
parameters. While virtually no other DBAPI assigns any use to the
setinputsizes()
call, the cx_Oracle DBAPI relies upon it heavily in its
interactions with the Oracle client interface, and in some scenarios it is not
possible for SQLAlchemy to know exactly how data should be bound, as some
settings can cause profoundly different performance characteristics, while
altering the type coercion behavior at the same time.
Users of the cx_Oracle dialect are strongly encouraged to read through
cx_Oracle’s list of built-in datatype symbols at http://cx-oracle.readthedocs.io/en/latest/module.html#types.
Note that in some cases, signficant performance degradation can occur when using
these types vs. not, in particular when specifying cx_Oracle.CLOB
.
On the SQLAlchemy side, the DialectEvents.do_setinputsizes()
event
can be used both for runtime visibliity (e.g. logging) of the setinputsizes
step as well as to fully control how setinputsizes()
is used on a per-statement
basis.
New in version 1.2.9: Added DialectEvents.setinputsizes()
The following example illustrates how to log the intermediary values from
a SQLAlchemy perspective before they are converted to the raw setinputsizes()
parameter dictionary. The keys of the dictionary are BindParameter
objects which have a .key
and a .type
attribute:
from sqlalchemy import create_engine, event
engine = create_engine("oracle+cx_oracle://scott:tiger@host/xe")
@event.listens_for(engine, "do_setinputsizes")
def _log_setinputsizes(inputsizes, cursor, statement, parameters, context):
for bindparam, dbapitype in inputsizes.items():
log.info(
"Bound parameter name: %s SQLAlchemy type: %r "
"DBAPI object: %s",
bindparam.key, bindparam.type, dbapitype)
The CLOB
datatype in cx_Oracle incurs a significant performance overhead,
however is set by default for the Text
type within the SQLAlchemy 1.2
series. This setting can be modified as follows:
from sqlalchemy import create_engine, event
from cx_Oracle import CLOB
engine = create_engine("oracle+cx_oracle://scott:tiger@host/xe")
@event.listens_for(engine, "do_setinputsizes")
def _remove_clob(inputsizes, cursor, statement, parameters, context):
for bindparam, dbapitype in list(inputsizes.items()):
if dbapitype is CLOB:
del inputsizes[bindparam]
The cx_Oracle dialect implements RETURNING using OUT parameters. The dialect supports RETURNING fully, however cx_Oracle 6 is recommended for complete support.
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, which takes place within a cx_Oracle outputtypehandler.
cx_Oracle prior to version 6 would require that LOB objects be read before
a new batch of rows would be read, as determined by the cursor.arraysize
.
As of the 6 series, this limitation has been lifted. Nevertheless, because
SQLAlchemy pre-reads these LOBs up front, this issue is avoided in any case.
To disable the auto “read()” feature of the dialect, the flag
auto_convert_lobs=False
may be passed to create_engine()
. Under
the cx_Oracle 5 series, having this flag turned off means there is the chance
of reading from a stale LOB object if not read as it is fetched. With
cx_Oracle 6, this issue is resolved.
Changed in version 1.2: the LOB handling system has been greatly simplified internally to make use of outputtypehandlers, and no longer makes use of alternate “buffered” result set objects.
Two phase transactions are not supported under cx_Oracle due to poor driver support. As of cx_Oracle 6.0b1, the interface for two phase transactions has been changed to be more of a direct pass-through to the underlying OCI layer with less automation. The additional logic to support this system is not implemented in SQLAlchemy.
SQLAlchemy’s numeric types can handle receiving and returning values as Python
Decimal
objects or float objects. When a Numeric
object, or a
subclass such as Float
, oracle.DOUBLE_PRECISION
etc. is in
use, the Numeric.asdecimal
flag determines if values should be
coerced to Decimal
upon return, or returned as float objects. To make
matters more complicated under Oracle, Oracle’s NUMBER
type can also
represent integer values if the “scale” is zero, so the Oracle-specific
oracle.NUMBER
type takes this into account as well.
The cx_Oracle dialect makes extensive use of connection- and cursor-level
“outputtypehandler” callables in order to coerce numeric values as requested.
These callables are specific to the specific flavor of Numeric
in
use, as well as if no SQLAlchemy typing objects are present. There are
observed scenarios where Oracle may sends incomplete or ambiguous information
about the numeric types being returned, such as a query where the numeric types
are buried under multiple levels of subquery. The type handlers do their best
to make the right decision in all cases, deferring to the underlying cx_Oracle
DBAPI for all those cases where the driver can make the best decision.
When no typing objects are present, as when executing plain SQL strings, a
default “outputtypehandler” is present which will generally return numeric
values which specify precision and scale as Python Decimal
objects. To
disable this coercion to decimal for performance reasons, pass the flag
coerce_to_decimal=False
to create_engine()
:
engine = create_engine("oracle+cx_oracle://dsn", coerce_to_decimal=False)
The coerce_to_decimal
flag only impacts the results of plain string
SQL staements that are not otherwise associated with a Numeric
SQLAlchemy type (or a subclass of such).
Changed in version 1.2: The numeric handling system for cx_Oracle has been reworked to take advantage of newer cx_Oracle features as well as better integration of outputtypehandlers.
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