cx_Oracle provides several methods of indicating the target database. The dialect translates from a series of different URL forms.
Given a hostname, port and service name of the target Oracle Database, for example from Oracle's Easy Connect syntax, then connect in SQLAlchemy using the service_name query string parameter:
engine = create_engine("oracle+cx_oracle://scott:tiger@hostname:port/?service_name=myservice&encoding=UTF-8&nencoding=UTF-8")
The full Easy Connect syntax is not supported. Instead, use a tnsnames.ora file and connect using a DSN.
Alternatively, if no port, database name, or service_name is provided, the dialect will use an Oracle DSN "connection string". This takes the "hostname" portion of the URL as the data source name. For example, if the tnsnames.ora file contains a Net Service Name of myalias as below:
myalias = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = mymachine.example.com)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = orclpdb1) ) )
The cx_Oracle dialect connects to this database service when myalias is the hostname portion of the URL, without specifying a port, database name or service_name:
engine = create_engine("oracle+cx_oracle://scott:tiger@myalias/?encoding=UTF-8&nencoding=UTF-8")
Users of Oracle Cloud should use this syntax and also configure the cloud wallet as shown in cx_Oracle documentation Connecting to Autononmous Databases.
To use Oracle's obsolete SID connection syntax, the SID can be passed in a "database name" portion of the URL as below:
engine = create_engine("oracle+cx_oracle://scott:tiger@hostname:1521/dbname?encoding=UTF-8&nencoding=UTF-8")
Above, the DSN passed to cx_Oracle is created by cx_Oracle.makedsn() as follows:
>>> import cx_Oracle >>> cx_Oracle.makedsn("hostname", 1521, sid="dbname") '(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=hostname)(PORT=1521))(CONNECT_DATA=(SID=dbname)))'
Additional connection arguments can usually be passed via the URL query string; particular symbols like cx_Oracle.SYSDBA are intercepted and converted to the correct symbol:
e = create_engine( "oracle+cx_oracle://user:pass@dsn?encoding=UTF-8&nencoding=UTF-8&mode=SYSDBA&events=true")
To pass arguments directly to .connect() without using the query string, use the :paramref:`_sa.create_engine.connect_args` dictionary. Any cx_Oracle parameter value and/or constant may be passed, such as:
import cx_Oracle e = create_engine( "oracle+cx_oracle://user:pass@dsn", connect_args={ "encoding": "UTF-8", "nencoding": "UTF-8", "mode": cx_Oracle.SYSDBA, "events": True } )
Note that the default value for encoding and nencoding was changed to "UTF-8" in cx_Oracle 8.0 so these parameters can be omitted when using that version, or later.
There are also options that are consumed by the SQLAlchemy cx_oracle dialect
itself. These options are always passed directly to _sa.create_engine
, such as:
e = create_engine( "oracle+cx_oracle://user:pass@dsn", coerce_to_unicode=False)
The parameters accepted by the cx_oracle dialect are as follows:
The cx_Oracle library provides its own connection pool implementation that may be used in place of SQLAlchemy's pooling functionality. This can be achieved by using the :paramref:`_sa.create_engine.creator` parameter to provide a function that returns a new connection, along with setting :paramref:`_sa.create_engine.pool_class` to NullPool to disable SQLAlchemy's pooling:
import cx_Oracle from sqlalchemy import create_engine from sqlalchemy.pool import NullPool pool = cx_Oracle.SessionPool( user="scott", password="tiger", dsn="orclpdb", min=2, max=5, increment=1, threaded=True, encoding="UTF-8", nencoding="UTF-8" ) engine = create_engine("oracle://", creator=pool.acquire, poolclass=NullPool)
The above engine may then be used normally where cx_Oracle's pool handles connection pooling:
with engine.connect() as conn: print(conn.scalar("select 1 FROM dual"))
As well as providing a scalable solution for multi-user applications, the cx_Oracle session pool supports some Oracle features such as DRCP and Application Continuity.
When using Oracle's DRCP, the best practice is to pass a connection class and "purity" when acquiring a connection from the SessionPool. Refer to the cx_Oracle DRCP documentation.
This can be achieved by wrapping pool.acquire():
import cx_Oracle from sqlalchemy import create_engine from sqlalchemy.pool import NullPool pool = cx_Oracle.SessionPool( user="scott", password="tiger", dsn="orclpdb", min=2, max=5, increment=1, threaded=True, encoding="UTF-8", nencoding="UTF-8" ) def creator(): return pool.acquire(cclass="MYCLASS", purity=cx_Oracle.ATTR_PURITY_SELF) engine = create_engine("oracle://", creator=creator, poolclass=NullPool)
The above engine may then be used normally where cx_Oracle handles session pooling and Oracle Database additionally uses DRCP:
with engine.connect() as conn: print(conn.scalar("select 1 FROM dual"))
As is the case for all DBAPIs under Python 3, all strings are inherently Unicode strings. Under Python 2, cx_Oracle also supports Python Unicode objects directly. In all cases however, the driver requires an explicit encoding configuration.
The long accepted standard for establishing client encoding for nearly all Oracle related software is via the NLS_LANG environment variable. cx_Oracle like most other Oracle drivers will use this environment variable as the source of its encoding configuration. The format of this variable is idiosyncratic; a typical value would be AMERICAN_AMERICA.AL32UTF8.
The cx_Oracle driver also supports a programmatic alternative which is to pass the encoding and nencoding parameters directly to its .connect() function. These can be present in the URL as follows:
engine = create_engine("oracle+cx_oracle://scott:tiger@orclpdb/?encoding=UTF-8&nencoding=UTF-8")
For the meaning of the encoding and nencoding parameters, please consult Characters Sets and National Language Support (NLS).
See Also
Characters Sets and National Language Support (NLS) - in the cx_Oracle documentation.
The Core expression language handles unicode data by use of the .Unicode
and .UnicodeText
datatypes. These types correspond to the VARCHAR2 and CLOB Oracle datatypes by
default. When using these datatypes with Unicode data, it is expected that
the Oracle database is configured with a Unicode-aware character set, as well
as that the NLS_LANG environment variable is set appropriately, so that
the VARCHAR2 and CLOB datatypes can accommodate the data.
In the case that the Oracle database is not configured with a Unicode character
set, the two options are to use the _types.NCHAR
and
_oracle.NCLOB
datatypes explicitly, or to pass the flag
use_nchar_for_unicode=True to _sa.create_engine
,
which will cause the
SQLAlchemy dialect to use NCHAR/NCLOB for the .Unicode
/
.UnicodeText
datatypes instead of VARCHAR/CLOB.
.Unicode
and .UnicodeText
datatypes now correspond to the VARCHAR2 and CLOB Oracle datatypes
unless the use_nchar_for_unicode=True is passed to the dialect
when _sa.create_engine
is called.When result sets are fetched that include strings, under Python 3 the cx_Oracle
DBAPI returns all strings as Python Unicode objects, since Python 3 only has a
Unicode string type. This occurs for data fetched from datatypes such as
VARCHAR2, CHAR, CLOB, NCHAR, NCLOB, etc. In order to provide cross-
compatibility under Python 2, the SQLAlchemy cx_Oracle dialect will add
Unicode-conversion to string data under Python 2 as well. Historically, this
made use of converters that were supplied by cx_Oracle but were found to be
non-performant; SQLAlchemy's own converters are used for the string to Unicode
conversion under Python 2. To disable the Python 2 Unicode conversion for
VARCHAR2, CHAR, and CLOB, the flag coerce_to_unicode=False can be passed to
_sa.create_engine
.
For the unusual case that data in the Oracle database is present with a broken encoding, the dialect accepts a parameter encoding_errors which will be passed to Unicode decoding functions in order to affect how decoding errors are handled. The value is ultimately consumed by the Python decode function, and is passed both via cx_Oracle's encodingErrors parameter consumed by Cursor.var(), as well as SQLAlchemy's own decoding function, as the cx_Oracle dialect makes use of both under different circumstances.
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 https://cx-oracle.readthedocs.io/en/latest/api_manual/module.html#database-types. Note that in some cases, significant 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 visibility (e.g. logging) of the setinputsizes step as
well as to fully control how setinputsizes() is used on a per-statement
basis.
.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 _sa.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.
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 :paramref:`.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 _sa.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 statements that are not otherwise associated with a .Numeric
SQLAlchemy type (or a subclass of such).
Class | _OracleBinary |
Undocumented |
Class | _OracleBINARY_DOUBLE |
Undocumented |
Class | _OracleBINARY_FLOAT |
Undocumented |
Class | _OracleBinaryFloat |
Undocumented |
Class | _OracleChar |
Undocumented |
Class | _OracleDate |
Undocumented |
Class | _OracleEnum |
Undocumented |
Class | _OracleInteger |
Undocumented |
Class | _OracleInterval |
Undocumented |
Class | _OracleLong |
Undocumented |
Class | _OracleNChar |
Undocumented |
Class | _OracleNUMBER |
Undocumented |
Class | _OracleNumeric |
Undocumented |
Class | _OracleRaw |
Undocumented |
Class | _OracleRowid |
Undocumented |
Class | _OracleString |
Undocumented |
Class | _OracleText |
Undocumented |
Class | _OracleUnicodeStringCHAR |
Undocumented |
Class | _OracleUnicodeStringNCHAR |
Undocumented |
Class | _OracleUnicodeTextCLOB |
Undocumented |
Class | _OracleUnicodeTextNCLOB |
Undocumented |
Class | OracleCompiler_cx_oracle |
Undocumented |
Class | OracleDialect_cx_oracle |
No class docstring; 0/1 property, 0/13 instance variable, 0/6 class variable, 2/20 methods, 0/1 class method documented |
Class | OracleExecutionContext_cx_oracle |
Undocumented |