From fefc32951bfababa731bd3cd7dcbe41b38062e98 Mon Sep 17 00:00:00 2001 From: Christopher Jones Date: Tue, 12 Nov 2024 10:59:56 +1100 Subject: [PATCH] Prefer official product name 'Oracle Database' Also made small fixes/updates to some examples Signed-off-by: Christopher Jones --- doc/build/core/connections.rst | 51 ++++++++++---------- doc/build/core/defaults.rst | 18 +++---- doc/build/core/pooling.rst | 21 ++++---- doc/build/core/type_basics.rst | 8 ++- doc/build/dialects/oracle.rst | 12 ++--- doc/build/glossary.rst | 24 ++++----- doc/build/index.rst | 3 +- doc/build/orm/persistence_techniques.rst | 12 ++--- doc/build/orm/queryguide/relationships.rst | 8 +-- doc/build/orm/relationship_persistence.rst | 23 ++++----- doc/build/orm/versioning.rst | 3 +- doc/build/tutorial/data_select.rst | 20 ++++---- lib/sqlalchemy/dialects/oracle/base.py | 18 +++---- lib/sqlalchemy/dialects/oracle/provision.py | 2 +- lib/sqlalchemy/dialects/oracle/types.py | 31 ++++++------ lib/sqlalchemy/engine/base.py | 19 ++++---- lib/sqlalchemy/engine/default.py | 14 +++--- lib/sqlalchemy/engine/events.py | 2 +- lib/sqlalchemy/engine/interfaces.py | 19 ++++---- lib/sqlalchemy/engine/reflection.py | 4 +- lib/sqlalchemy/ext/compiler.py | 2 +- lib/sqlalchemy/orm/context.py | 4 +- lib/sqlalchemy/sql/_elements_constructors.py | 4 +- lib/sqlalchemy/sql/compiler.py | 2 +- lib/sqlalchemy/sql/elements.py | 10 ++-- lib/sqlalchemy/sql/operators.py | 10 ++-- lib/sqlalchemy/sql/schema.py | 24 ++++----- lib/sqlalchemy/sql/selectable.py | 38 +++++++-------- lib/sqlalchemy/sql/sqltypes.py | 34 ++++++------- reap_dbs.py | 2 +- 30 files changed, 222 insertions(+), 220 deletions(-) diff --git a/doc/build/core/connections.rst b/doc/build/core/connections.rst index 597d317f07..eb76822ba3 100644 --- a/doc/build/core/connections.rst +++ b/doc/build/core/connections.rst @@ -419,7 +419,7 @@ reverted when a connection is returned to the connection pool. :ref:`SQL Server Transaction Isolation ` - :ref:`Oracle Transaction Isolation ` + :ref:`Oracle Database Transaction Isolation ` :ref:`session_transaction_isolation` - for the ORM @@ -588,17 +588,17 @@ To sum up: Using Server Side Cursors (a.k.a. stream results) ------------------------------------------------- -Some backends feature explicit support for the concept of "server -side cursors" versus "client side cursors". A client side cursor here -means that the database driver fully fetches all rows from a result set -into memory before returning from a statement execution. Drivers such as -those of PostgreSQL and MySQL/MariaDB generally use client side cursors -by default. A server side cursor, by contrast, indicates that result rows -remain pending within the database server's state as result rows are consumed -by the client. The drivers for Oracle generally use a "server side" model, -for example, and the SQLite dialect, while not using a real "client / server" -architecture, still uses an unbuffered result fetching approach that will -leave result rows outside of process memory before they are consumed. +Some backends feature explicit support for the concept of "server side cursors" +versus "client side cursors". A client side cursor here means that the +database driver fully fetches all rows from a result set into memory before +returning from a statement execution. Drivers such as those of PostgreSQL and +MySQL/MariaDB generally use client side cursors by default. A server side +cursor, by contrast, indicates that result rows remain pending within the +database server's state as result rows are consumed by the client. The drivers +for Oracle Database generally use a "server side" model, for example, and the +SQLite dialect, while not using a real "client / server" architecture, still +uses an unbuffered result fetching approach that will leave result rows outside +of process memory before they are consumed. .. topic:: What we really mean is "buffered" vs. "unbuffered" results @@ -1807,17 +1807,18 @@ Current Support ~~~~~~~~~~~~~~~ The feature is enabled for all backend included in SQLAlchemy that support -RETURNING, with the exception of Oracle for which both the cx_Oracle and -OracleDB drivers offer their own equivalent feature. The feature normally takes -place when making use of the :meth:`_dml.Insert.returning` method of an -:class:`_dml.Insert` construct in conjunction with :term:`executemany` -execution, which occurs when passing a list of dictionaries to the -:paramref:`_engine.Connection.execute.parameters` parameter of the -:meth:`_engine.Connection.execute` or :meth:`_orm.Session.execute` methods (as -well as equivalent methods under :ref:`asyncio ` and -shorthand methods like :meth:`_orm.Session.scalars`). It also takes place -within the ORM :term:`unit of work` process when using methods such as -:meth:`_orm.Session.add` and :meth:`_orm.Session.add_all` to add rows. +RETURNING, with the exception of Oracle Database for which both the +python-oracledb and cx_Oracle drivers offer their own equivalent feature. The +feature normally takes place when making use of the +:meth:`_dml.Insert.returning` method of an :class:`_dml.Insert` construct in +conjunction with :term:`executemany` execution, which occurs when passing a +list of dictionaries to the :paramref:`_engine.Connection.execute.parameters` +parameter of the :meth:`_engine.Connection.execute` or +:meth:`_orm.Session.execute` methods (as well as equivalent methods under +:ref:`asyncio ` and shorthand methods like +:meth:`_orm.Session.scalars`). It also takes place within the ORM :term:`unit +of work` process when using methods such as :meth:`_orm.Session.add` and +:meth:`_orm.Session.add_all` to add rows. For SQLAlchemy's included dialects, support or equivalent support is currently as follows: @@ -1827,8 +1828,8 @@ as follows: * SQL Server - all supported SQL Server versions [#]_ * MariaDB - supported for MariaDB versions 10.5 and above * MySQL - no support, no RETURNING feature is present -* Oracle - supports RETURNING with executemany using native cx_Oracle / OracleDB - APIs, for all supported Oracle versions 9 and above, using multi-row OUT +* Oracle Database - supports RETURNING with executemany using native python-oracledb / cx_Oracle + APIs, for all supported Oracle Databae versions 9 and above, using multi-row OUT parameters. This is not the same implementation as "executemanyvalues", however has the same usage patterns and equivalent performance benefits. diff --git a/doc/build/core/defaults.rst b/doc/build/core/defaults.rst index ef5ad20815..586f053143 100644 --- a/doc/build/core/defaults.rst +++ b/doc/build/core/defaults.rst @@ -349,7 +349,7 @@ SQLAlchemy represents database sequences using the :class:`~sqlalchemy.schema.Sequence` object, which is considered to be a special case of "column default". It only has an effect on databases which have explicit support for sequences, which among SQLAlchemy's included dialects -includes PostgreSQL, Oracle, MS SQL Server, and MariaDB. The +includes PostgreSQL, Oracle Database, MS SQL Server, and MariaDB. The :class:`~sqlalchemy.schema.Sequence` object is otherwise ignored. .. tip:: @@ -466,8 +466,8 @@ column:: In the above example, ``CREATE TABLE`` for PostgreSQL will make use of the ``SERIAL`` datatype for the ``cart_id`` column, and the ``cart_id_seq`` -sequence will be ignored. However on Oracle, the ``cart_id_seq`` sequence -will be created explicitly. +sequence will be ignored. However on Oracle Database, the ``cart_id_seq`` +sequence will be created explicitly. .. tip:: @@ -544,7 +544,7 @@ Associating a Sequence as the Server Side Default ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .. note:: The following technique is known to work only with the PostgreSQL - database. It does not work with Oracle. + database. It does not work with Oracle Database. The preceding sections illustrate how to associate a :class:`.Sequence` with a :class:`_schema.Column` as the **Python side default generator**:: @@ -627,7 +627,7 @@ including the default schema, if any. :ref:`postgresql_sequences` - in the PostgreSQL dialect documentation - :ref:`oracle_returning` - in the Oracle dialect documentation + :ref:`oracle_returning` - in the Oracle Database dialect documentation .. _computed_ddl: @@ -704,9 +704,9 @@ eagerly fetched. * PostgreSQL as of version 12 -* Oracle - with the caveat that RETURNING does not work correctly with UPDATE - (a warning will be emitted to this effect when the UPDATE..RETURNING that - includes a computed column is rendered) +* Oracle Database - with the caveat that RETURNING does not work correctly with + UPDATE (a warning will be emitted to this effect when the UPDATE..RETURNING + that includes a computed column is rendered) * Microsoft SQL Server @@ -792,7 +792,7 @@ The :class:`.Identity` construct is currently known to be supported by: * PostgreSQL as of version 10. -* Oracle as of version 12. It also supports passing ``always=None`` to +* Oracle Database as of version 12. It also supports passing ``always=None`` to enable the default generated mode and the parameter ``on_null=True`` to specify "ON NULL" in conjunction with a "BY DEFAULT" identity column. diff --git a/doc/build/core/pooling.rst b/doc/build/core/pooling.rst index f3ea6e8623..526782b055 100644 --- a/doc/build/core/pooling.rst +++ b/doc/build/core/pooling.rst @@ -509,30 +509,32 @@ particular error should be considered a "disconnect" situation or not, as well as if this disconnect should cause the entire connection pool to be invalidated or not. -For example, to add support to consider the Oracle error codes -``DPY-1001`` and ``DPY-4011`` to be handled as disconnect codes, apply an -event handler to the engine after creation:: +For example, to add support to consider the Oracle Database driver error codes +``DPY-1001`` and ``DPY-4011`` to be handled as disconnect codes, apply an event +handler to the engine after creation:: import re from sqlalchemy import create_engine - engine = create_engine("oracle://scott:tiger@dnsname") + engine = create_engine( + "oracle+oracledb://scott:tiger@localhost:1521?service_name=freepdb1" + ) @event.listens_for(engine, "handle_error") def handle_exception(context: ExceptionContext) -> None: if not context.is_disconnect and re.match( - r"^(?:DPI-1001|DPI-4011)", str(context.original_exception) + r"^(?:DPY-1001|DPY-4011)", str(context.original_exception) ): context.is_disconnect = True return None -The above error processing function will be invoked for all Oracle errors -raised, including those caught when using the -:ref:`pool pre ping ` feature for those backends -that rely upon disconnect error handling (new in 2.0). +The above error processing function will be invoked for all Oracle Database +errors raised, including those caught when using the :ref:`pool pre ping +` feature for those backends that rely upon +disconnect error handling (new in 2.0). .. seealso:: @@ -760,4 +762,3 @@ API Documentation - Available Pool Implementations .. autoclass:: _ConnectionFairy .. autoclass:: _ConnectionRecord - diff --git a/doc/build/core/type_basics.rst b/doc/build/core/type_basics.rst index f3817fe0c9..817bca601a 100644 --- a/doc/build/core/type_basics.rst +++ b/doc/build/core/type_basics.rst @@ -63,9 +63,9 @@ not every backend has a real "boolean" datatype; some make use of integers or BIT values 0 and 1, some have boolean literal constants ``true`` and ``false`` while others dont. For this datatype, :class:`_types.Boolean` may render ``BOOLEAN`` on a backend such as PostgreSQL, ``BIT`` on the -MySQL backend and ``SMALLINT`` on Oracle. As data is sent and received -from the database using this type, based on the dialect in use it may be -interpreting Python numeric or boolean values. +MySQL backend and ``SMALLINT`` on Oracle Database. As data is sent and +received from the database using this type, based on the dialect in use it +may be interpreting Python numeric or boolean values. The typical SQLAlchemy application will likely wish to use primarily "CamelCase" types in the general case, as they will generally provide the best @@ -336,5 +336,3 @@ its exact name in DDL with ``CREATE TABLE`` is issued. .. autoclass:: VARCHAR - - diff --git a/doc/build/dialects/oracle.rst b/doc/build/dialects/oracle.rst index 6dee870ceb..b3d44858ce 100644 --- a/doc/build/dialects/oracle.rst +++ b/doc/build/dialects/oracle.rst @@ -5,12 +5,12 @@ Oracle .. automodule:: sqlalchemy.dialects.oracle.base -Oracle Data Types ------------------ +Oracle Database Data Types +-------------------------- -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 :mod:`sqlalchemy.types` or from the local dialect:: +As with all SQLAlchemy dialects, all UPPERCASE types that are known to be valid +with Oracle Database are importable from the top level dialect, whether they +originate from :mod:`sqlalchemy.types` or from the local dialect:: from sqlalchemy.dialects.oracle import ( BFILE, @@ -36,7 +36,7 @@ they originate from :mod:`sqlalchemy.types` or from the local dialect:: .. versionadded:: 1.2.19 Added :class:`_types.NCHAR` to the list of datatypes exported by the Oracle dialect. -Types which are specific to Oracle, or have Oracle-specific +Types which are specific to Oracle Database, or have Oracle-specific construction arguments, are as follows: .. currentmodule:: sqlalchemy.dialects.oracle diff --git a/doc/build/glossary.rst b/doc/build/glossary.rst index a7422bd97b..05d88a4f26 100644 --- a/doc/build/glossary.rst +++ b/doc/build/glossary.rst @@ -298,7 +298,7 @@ Glossary A key limitation of the ``cursor.executemany()`` method as used with all known DBAPIs is that the ``cursor`` is not configured to return rows when this method is used. For **most** backends (a notable - exception being the cx_Oracle, / OracleDB DBAPIs), this means that + exception being the python-oracledb / cx_Oracle DBAPIs), this means that statements like ``INSERT..RETURNING`` typically cannot be used with ``cursor.executemany()`` directly, since DBAPIs typically do not aggregate the single row from each INSERT execution together. @@ -1158,16 +1158,17 @@ Glossary values as they are not included otherwise (but note any series of columns or SQL expressions can be placed into RETURNING, not just default-value columns). - The backends that currently support - RETURNING or a similar construct are PostgreSQL, SQL Server, Oracle, - and Firebird. The PostgreSQL and Firebird implementations are generally - full featured, whereas the implementations of SQL Server and Oracle - have caveats. On SQL Server, the clause is known as "OUTPUT INSERTED" - for INSERT and UPDATE statements and "OUTPUT DELETED" for DELETE statements; - the key caveat is that triggers are not supported in conjunction with this - keyword. On Oracle, it is known as "RETURNING...INTO", and requires that the - value be placed into an OUT parameter, meaning not only is the syntax awkward, - but it can also only be used for one row at a time. + The backends that currently support RETURNING or a similar construct + are PostgreSQL, SQL Server, Oracle Database, and Firebird. The + PostgreSQL and Firebird implementations are generally full featured, + whereas the implementations of SQL Server and Oracle have caveats. On + SQL Server, the clause is known as "OUTPUT INSERTED" for INSERT and + UPDATE statements and "OUTPUT DELETED" for DELETE statements; the key + caveat is that triggers are not supported in conjunction with this + keyword. In Oracle Database, it is known as "RETURNING...INTO", and + requires that the value be placed into an OUT parameter, meaning not + only is the syntax awkward, but it can also only be used for one row at + a time. SQLAlchemy's :meth:`.UpdateBase.returning` system provides a layer of abstraction on top of the RETURNING systems of these backends to provide a consistent @@ -1702,4 +1703,3 @@ Glossary .. seealso:: :ref:`session_object_states` - diff --git a/doc/build/index.rst b/doc/build/index.rst index ff395e413c..4a0065226a 100644 --- a/doc/build/index.rst +++ b/doc/build/index.rst @@ -160,7 +160,7 @@ SQLAlchemy Documentation :doc:`PostgreSQL ` | :doc:`MySQL and MariaDB ` | :doc:`SQLite ` | - :doc:`Oracle ` | + :doc:`Oracle Database ` | :doc:`Microsoft SQL Server ` :doc:`More Dialects ... ` @@ -180,4 +180,3 @@ SQLAlchemy Documentation * :doc:`Error Message Guide ` - Explanations of many SQLAlchemy Errors * :doc:`Complete table of of contents ` * :ref:`Index ` - diff --git a/doc/build/orm/persistence_techniques.rst b/doc/build/orm/persistence_techniques.rst index c7741ef9c2..a877fcd0e0 100644 --- a/doc/build/orm/persistence_techniques.rst +++ b/doc/build/orm/persistence_techniques.rst @@ -37,7 +37,7 @@ from the database. The feature also has conditional support to work in conjunction with primary key columns. For backends that have RETURNING support -(including Oracle, SQL Server, MariaDB 10.5, SQLite 3.35) a +(including Oracle Database, SQL Server, MariaDB 10.5, SQLite 3.35) a SQL expression may be assigned to a primary key column as well. This allows both the SQL expression to be evaluated, as well as allows any server side triggers that modify the primary key value on INSERT, to be successfully @@ -274,7 +274,7 @@ answered are, 1. is this column part of the primary key or not, and 2. does the database support RETURNING or an equivalent, such as "OUTPUT inserted"; these are SQL phrases which return a server-generated value at the same time as the INSERT or UPDATE statement is invoked. RETURNING is currently supported -by PostgreSQL, Oracle, MariaDB 10.5, SQLite 3.35, and SQL Server. +by PostgreSQL, Oracle Database, MariaDB 10.5, SQLite 3.35, and SQL Server. Case 1: non primary key, RETURNING or equivalent is supported ------------------------------------------------------------- @@ -438,7 +438,7 @@ PostgreSQL SERIAL, these types are handled automatically by the Core; databases include functions for fetching the "last inserted id" where RETURNING is not supported, and where RETURNING is supported SQLAlchemy will use that. -For example, using Oracle with a column marked as :class:`.Identity`, +For example, using Oracle Database with a column marked as :class:`.Identity`, RETURNING is used automatically to fetch the new primary key value:: class MyOracleModel(Base): @@ -447,7 +447,7 @@ RETURNING is used automatically to fetch the new primary key value:: id: Mapped[int] = mapped_column(Identity(), primary_key=True) data: Mapped[str] = mapped_column(String(50)) -The INSERT for a model as above on Oracle looks like: +The INSERT for a model as above on Oracle Database looks like: .. sourcecode:: sql @@ -460,7 +460,7 @@ place and the new value will be returned immediately. For non-integer values generated by server side functions or triggers, as well as for integer values that come from constructs outside the table itself, including explicit sequences and triggers, the server default generation must -be marked in the table metadata. Using Oracle as the example again, we can +be marked in the table metadata. Using Oracle Database as the example again, we can illustrate a similar table as above naming an explicit sequence using the :class:`.Sequence` construct:: @@ -470,7 +470,7 @@ illustrate a similar table as above naming an explicit sequence using the id: Mapped[int] = mapped_column(Sequence("my_oracle_seq"), primary_key=True) data: Mapped[str] = mapped_column(String(50)) -An INSERT for this version of the model on Oracle would look like: +An INSERT for this version of the model on Oracle Database would look like: .. sourcecode:: sql diff --git a/doc/build/orm/queryguide/relationships.rst b/doc/build/orm/queryguide/relationships.rst index bf6f692b98..d63ae67ac7 100644 --- a/doc/build/orm/queryguide/relationships.rst +++ b/doc/build/orm/queryguide/relationships.rst @@ -828,10 +828,10 @@ will JOIN across all three tables to match rows from one side to the other. Things to know about this kind of loading include: * The strategy emits a SELECT for up to 500 parent primary key values at a - time, as the primary keys are rendered into a large IN expression in the - SQL statement. Some databases like Oracle have a hard limit on how large - an IN expression can be, and overall the size of the SQL string shouldn't - be arbitrarily large. + time, as the primary keys are rendered into a large IN expression in the SQL + statement. Some databases like Oracle Database have a hard limit on how + large an IN expression can be, and overall the size of the SQL string + shouldn't be arbitrarily large. * As "selectin" loading relies upon IN, for a mapping with composite primary keys, it must use the "tuple" form of IN, which looks like ``WHERE diff --git a/doc/build/orm/relationship_persistence.rst b/doc/build/orm/relationship_persistence.rst index 9a5a036c69..ba686d691d 100644 --- a/doc/build/orm/relationship_persistence.rst +++ b/doc/build/orm/relationship_persistence.rst @@ -35,12 +35,13 @@ Or: 1 'somewidget' 5 5 'someentry' 1 In the first case, a row points to itself. Technically, a database that uses -sequences such as PostgreSQL or Oracle can INSERT the row at once using a -previously generated value, but databases which rely upon autoincrement-style -primary key identifiers cannot. The :func:`~sqlalchemy.orm.relationship` -always assumes a "parent/child" model of row population during flush, so -unless you are populating the primary key/foreign key columns directly, -:func:`~sqlalchemy.orm.relationship` needs to use two statements. +sequences such as PostgreSQL or Oracle Database can INSERT the row at once +using a previously generated value, but databases which rely upon +autoincrement-style primary key identifiers cannot. The +:func:`~sqlalchemy.orm.relationship` always assumes a "parent/child" model of +row population during flush, so unless you are populating the primary +key/foreign key columns directly, :func:`~sqlalchemy.orm.relationship` needs to +use two statements. In the second case, the "widget" row must be inserted before any referring "entry" rows, but then the "favorite_entry_id" column of that "widget" row @@ -243,7 +244,7 @@ by emitting an UPDATE statement against foreign key columns that immediately reference a primary key column whose value has changed. The primary platforms without referential integrity features are MySQL when the ``MyISAM`` storage engine is used, and SQLite when the -``PRAGMA foreign_keys=ON`` pragma is not used. The Oracle database also +``PRAGMA foreign_keys=ON`` pragma is not used. Oracle Database also has no support for ``ON UPDATE CASCADE``, but because it still enforces referential integrity, needs constraints to be marked as deferrable so that SQLAlchemy can emit UPDATE statements. @@ -297,7 +298,7 @@ Key limitations of ``passive_updates=False`` include: map for objects that may be referencing the one with a mutating primary key, not throughout the database. -As virtually all databases other than Oracle now support ``ON UPDATE CASCADE``, -it is highly recommended that traditional ``ON UPDATE CASCADE`` support be used -in the case that natural and mutable primary key values are in use. - +As virtually all databases other than Oracle Database now support ``ON UPDATE +CASCADE``, it is highly recommended that traditional ``ON UPDATE CASCADE`` +support be used in the case that natural and mutable primary key values are in +use. diff --git a/doc/build/orm/versioning.rst b/doc/build/orm/versioning.rst index 87865917cd..7f209e24b2 100644 --- a/doc/build/orm/versioning.rst +++ b/doc/build/orm/versioning.rst @@ -207,7 +207,8 @@ missed version counters: It is *strongly recommended* that server side version counters only be used when absolutely necessary and only on backends that support :term:`RETURNING`, -currently PostgreSQL, Oracle, MariaDB 10.5, SQLite 3.35, and SQL Server. +currently PostgreSQL, Oracle Database, MariaDB 10.5, SQLite 3.35, and SQL +Server. Programmatic or Conditional Version Counters diff --git a/doc/build/tutorial/data_select.rst b/doc/build/tutorial/data_select.rst index d9d51c7f51..5052a5bae3 100644 --- a/doc/build/tutorial/data_select.rst +++ b/doc/build/tutorial/data_select.rst @@ -1387,8 +1387,8 @@ At the same time, a relatively small set of extremely common SQL functions such as :class:`_functions.count`, :class:`_functions.now`, :class:`_functions.max`, :class:`_functions.concat` include pre-packaged versions of themselves which provide for proper typing information as well as backend-specific SQL -generation in some cases. The example below contrasts the SQL generation -that occurs for the PostgreSQL dialect compared to the Oracle dialect for +generation in some cases. The example below contrasts the SQL generation that +occurs for the PostgreSQL dialect compared to the Oracle Database dialect for the :class:`_functions.now` function:: >>> from sqlalchemy.dialects import postgresql @@ -1683,10 +1683,10 @@ Table-Valued Functions Table-valued SQL functions support a scalar representation that contains named sub-elements. Often used for JSON and ARRAY-oriented functions as well as functions like ``generate_series()``, the table-valued function is specified in -the FROM clause, and is then referenced as a table, or sometimes even as -a column. Functions of this form are prominent within the PostgreSQL database, +the FROM clause, and is then referenced as a table, or sometimes even as a +column. Functions of this form are prominent within the PostgreSQL database, however some forms of table valued functions are also supported by SQLite, -Oracle, and SQL Server. +Oracle Database, and SQL Server. .. seealso:: @@ -1735,9 +1735,9 @@ towards as ``value``, and then selected two of its three rows. Column Valued Functions - Table Valued Function as a Scalar Column ################################################################## -A special syntax supported by PostgreSQL and Oracle is that of referring -towards a function in the FROM clause, which then delivers itself as a -single column in the columns clause of a SELECT statement or other column +A special syntax supported by PostgreSQL and Oracle Database is that of +referring towards a function in the FROM clause, which then delivers itself as +a single column in the columns clause of a SELECT statement or other column expression context. PostgreSQL makes great use of this syntax for such functions as ``json_array_elements()``, ``json_object_keys()``, ``json_each_text()``, ``json_each()``, etc. @@ -1752,8 +1752,8 @@ to a :class:`_functions.Function` construct:: {printsql}SELECT x FROM json_array_elements(:json_array_elements_1) AS x -The "column valued" form is also supported by the Oracle dialect, where -it is usable for custom SQL functions:: +The "column valued" form is also supported by the Oracle Database dialects, +where it is usable for custom SQL functions:: >>> from sqlalchemy.dialects import oracle >>> stmt = select(func.scalar_strings(5).column_valued("s")) diff --git a/lib/sqlalchemy/dialects/oracle/base.py b/lib/sqlalchemy/dialects/oracle/base.py index e83204b39c..0d51b3e034 100644 --- a/lib/sqlalchemy/dialects/oracle/base.py +++ b/lib/sqlalchemy/dialects/oracle/base.py @@ -9,7 +9,7 @@ r""" .. dialect:: oracle - :name: Oracle + :name: Oracle Database :normal_support: 11+ :best_effort: 9+ @@ -125,7 +125,7 @@ Valid values for ``isolation_level`` include: Additionally, the :meth:`_engine.Connection.get_isolation_level` method will raise an exception if the ``v$transaction`` view is not available due to - permissions or other reasons, which is a common occurrence in Oracle + permissions or other reasons, which is a common occurrence in Oracle Database installations. The python-oracledb and cx_Oracle dialects attempt to call the @@ -962,10 +962,10 @@ class OracleCompiler(compiler.SQLCompiler): and not self.dialect._supports_update_returning_computed_cols ): util.warn( - "Computed columns don't work with Oracle UPDATE " + "Computed columns don't work with Oracle Database UPDATE " "statements that use RETURNING; the value of the column " "*before* the UPDATE takes place is returned. It is " - "advised to not use RETURNING with an Oracle computed " + "advised to not use RETURNING with an Oracle Database computed " "column. Consider setting implicit_returning to False on " "the Table object in order to avoid implicit RETURNING " "clauses from being generated for this Table." @@ -992,7 +992,7 @@ class OracleCompiler(compiler.SQLCompiler): raise exc.InvalidRequestError( "Using explicit outparam() objects with " "UpdateBase.returning() in the same Core DML statement " - "is not supported in the Oracle dialect." + "is not supported in the Oracle Database dialects." ) self._oracle_returning = True @@ -1013,7 +1013,7 @@ class OracleCompiler(compiler.SQLCompiler): return "RETURNING " + ", ".join(columns) + " INTO " + ", ".join(binds) def _row_limit_clause(self, select, **kw): - """ORacle 12c supports OFFSET/FETCH operators + """Oracle Database 12c supports OFFSET/FETCH operators Use it instead subquery with row_number """ @@ -1297,7 +1297,7 @@ class OracleDDLCompiler(compiler.DDLCompiler): # https://web.archive.org/web/20090317041251/https://asktom.oracle.com/tkyte/update_cascade/index.html if constraint.onupdate is not None: util.warn( - "Oracle does not contain native UPDATE CASCADE " + "Oracle Database does not contain native UPDATE CASCADE " "functionality - onupdates will not be rendered for foreign " "keys. Consider using deferrable=True, initially='deferred' " "or triggers." @@ -1373,8 +1373,8 @@ class OracleDDLCompiler(compiler.DDLCompiler): ) if generated.persisted is True: raise exc.CompileError( - "Oracle computed columns do not support 'stored' persistence; " - "set the 'persisted' flag to None or False for Oracle support." + "Oracle Database computed columns do not support 'stored' persistence; " + "set the 'persisted' flag to None or False for Oracle Database support." ) elif generated.persisted is False: text += " VIRTUAL" diff --git a/lib/sqlalchemy/dialects/oracle/provision.py b/lib/sqlalchemy/dialects/oracle/provision.py index b33c1525cd..0eb6273a8c 100644 --- a/lib/sqlalchemy/dialects/oracle/provision.py +++ b/lib/sqlalchemy/dialects/oracle/provision.py @@ -89,7 +89,7 @@ def _oracle_drop_db(cfg, eng, ident): # cx_Oracle seems to occasionally leak open connections when a large # suite it run, even if we confirm we have zero references to # connection objects. - # while there is a "kill session" command in Oracle, + # while there is a "kill session" command in Oracle Database, # it unfortunately does not release the connection sufficiently. _ora_drop_ignore(conn, ident) _ora_drop_ignore(conn, "%s_ts1" % ident) diff --git a/lib/sqlalchemy/dialects/oracle/types.py b/lib/sqlalchemy/dialects/oracle/types.py index 36caaa05e6..c75fbd9f7a 100644 --- a/lib/sqlalchemy/dialects/oracle/types.py +++ b/lib/sqlalchemy/dialects/oracle/types.py @@ -64,17 +64,18 @@ class NUMBER(sqltypes.Numeric, sqltypes.Integer): class FLOAT(sqltypes.FLOAT): - """Oracle FLOAT. + """Oracle Database FLOAT. This is the same as :class:`_sqltypes.FLOAT` except that - an Oracle-specific :paramref:`_oracle.FLOAT.binary_precision` + an Oracle Database -specific :paramref:`_oracle.FLOAT.binary_precision` parameter is accepted, and the :paramref:`_sqltypes.Float.precision` parameter is not accepted. - Oracle FLOAT types indicate precision in terms of "binary precision", which - defaults to 126. For a REAL type, the value is 63. This parameter does not - cleanly map to a specific number of decimal places but is roughly - equivalent to the desired number of decimal places divided by 0.3103. + Oracle Database FLOAT types indicate precision in terms of "binary + precision", which defaults to 126. For a REAL type, the value is 63. This + parameter does not cleanly map to a specific number of decimal places but + is roughly equivalent to the desired number of decimal places divided by + 0.3103. .. versionadded:: 2.0 @@ -91,10 +92,10 @@ class FLOAT(sqltypes.FLOAT): r""" Construct a FLOAT - :param binary_precision: Oracle binary precision value to be rendered + :param binary_precision: Oracle Database binary precision value to be rendered in DDL. This may be approximated to the number of decimal characters using the formula "decimal precision = 0.30103 * binary precision". - The default value used by Oracle for FLOAT / DOUBLE PRECISION is 126. + The default value used by Oracle Database for FLOAT / DOUBLE PRECISION is 126. :param asdecimal: See :paramref:`_sqltypes.Float.asdecimal` @@ -163,10 +164,10 @@ class _OracleDateLiteralRender: class DATE(_OracleDateLiteralRender, sqltypes.DateTime): - """Provide the oracle DATE type. + """Provide the Oracle Database DATE type. This type has no special Python behavior, except that it subclasses - :class:`_types.DateTime`; this is to suit the fact that the Oracle + :class:`_types.DateTime`; this is to suit the fact that the Oracle Database ``DATE`` type supports a time value. """ @@ -246,8 +247,8 @@ class INTERVAL(sqltypes.NativeForEmulated, sqltypes._AbstractInterval): class TIMESTAMP(sqltypes.TIMESTAMP): - """Oracle implementation of ``TIMESTAMP``, which supports additional - Oracle-specific modes + """Oracle Database implementation of ``TIMESTAMP``, which supports + additional Oracle Database-specific modes .. versionadded:: 2.0 @@ -257,10 +258,10 @@ class TIMESTAMP(sqltypes.TIMESTAMP): """Construct a new :class:`_oracle.TIMESTAMP`. :param timezone: boolean. Indicates that the TIMESTAMP type should - use Oracle's ``TIMESTAMP WITH TIME ZONE`` datatype. + use Oracle Database's ``TIMESTAMP WITH TIME ZONE`` datatype. :param local_timezone: boolean. Indicates that the TIMESTAMP type - should use Oracle's ``TIMESTAMP WITH LOCAL TIME ZONE`` datatype. + should use Oracle Database's ``TIMESTAMP WITH LOCAL TIME ZONE`` datatype. """ @@ -273,7 +274,7 @@ class TIMESTAMP(sqltypes.TIMESTAMP): class ROWID(sqltypes.TypeEngine): - """Oracle ROWID type. + """Oracle Database ROWID type. When used in a cast() or similar, generates ROWID. diff --git a/lib/sqlalchemy/engine/base.py b/lib/sqlalchemy/engine/base.py index a06880ca2d..13ec3d639a 100644 --- a/lib/sqlalchemy/engine/base.py +++ b/lib/sqlalchemy/engine/base.py @@ -383,12 +383,11 @@ class Connection(ConnectionEventsTarget, inspection.Inspectable["Inspector"]): :param stream_results: Available on: :class:`_engine.Connection`, :class:`_sql.Executable`. - Indicate to the dialect that results should be - "streamed" and not pre-buffered, if possible. For backends - such as PostgreSQL, MySQL and MariaDB, this indicates the use of - a "server side cursor" as opposed to a client side cursor. - Other backends such as that of Oracle may already use server - side cursors by default. + Indicate to the dialect that results should be "streamed" and not + pre-buffered, if possible. For backends such as PostgreSQL, MySQL + and MariaDB, this indicates the use of a "server side cursor" as + opposed to a client side cursor. Other backends such as that of + Oracle Database may already use server side cursors by default. The usage of :paramref:`_engine.Connection.execution_options.stream_results` is @@ -521,10 +520,10 @@ class Connection(ConnectionEventsTarget, inspection.Inspectable["Inspector"]): ``cursor.description`` to set up the keys for the result set, including the names of columns for the :class:`_engine.Row` object as well as the dictionary keys when using :attr:`_engine.Row._mapping`. - On backends that use "name normalization" such as Oracle to correct - for lower case names being converted to all uppercase, this behavior - is turned off and the raw UPPERCASE names in cursor.description will - be present. + On backends that use "name normalization" such as Oracle Database to + correct for lower case names being converted to all uppercase, this + behavior is turned off and the raw UPPERCASE names in + cursor.description will be present. .. versionadded:: 2.1 diff --git a/lib/sqlalchemy/engine/default.py b/lib/sqlalchemy/engine/default.py index 616d284d31..d8fc7cda82 100644 --- a/lib/sqlalchemy/engine/default.py +++ b/lib/sqlalchemy/engine/default.py @@ -395,7 +395,8 @@ class DefaultDialect(Dialect): available if the dialect in use has opted into using the "use_insertmanyvalues" feature. If they haven't opted into that, then this attribute is False, unless the dialect in question overrides this - and provides some other implementation (such as the Oracle dialect). + and provides some other implementation (such as the Oracle Database + dialects). """ return self.insert_returning and self.use_insertmanyvalues @@ -418,7 +419,7 @@ class DefaultDialect(Dialect): If the dialect in use hasn't opted into that, then this attribute is False, unless the dialect in question overrides this and provides some - other implementation (such as the Oracle dialect). + other implementation (such as the Oracle Database dialects). """ return self.insert_returning and self.use_insertmanyvalues @@ -2059,10 +2060,11 @@ class DefaultExecutionContext(ExecutionContext): style of ``setinputsizes()`` on the cursor, using DB-API types from the bind parameter's ``TypeEngine`` objects. - This method only called by those dialects which set - the :attr:`.Dialect.bind_typing` attribute to - :attr:`.BindTyping.SETINPUTSIZES`. cx_Oracle is the only DBAPI - that requires setinputsizes(), pyodbc offers it as an option. + This method only called by those dialects which set the + :attr:`.Dialect.bind_typing` attribute to + :attr:`.BindTyping.SETINPUTSIZES`. Python-oracledb and cx_Oracle are + the only DBAPIs that requires setinputsizes(); pyodbc offers it as an + option. Prior to SQLAlchemy 2.0, the setinputsizes() approach was also used for pg8000 and asyncpg, which has been changed to inline rendering diff --git a/lib/sqlalchemy/engine/events.py b/lib/sqlalchemy/engine/events.py index 2416cd989f..0323700c40 100644 --- a/lib/sqlalchemy/engine/events.py +++ b/lib/sqlalchemy/engine/events.py @@ -930,7 +930,7 @@ class DialectEvents(event.Events[Dialect]): The setinputsizes hook overall is only used for dialects which include the flag ``use_setinputsizes=True``. Dialects which use this - include cx_Oracle, pg8000, asyncpg, and pyodbc dialects. + include python-oracledb, cx_Oracle, pg8000, asyncpg, and pyodbc dialects. .. note:: diff --git a/lib/sqlalchemy/engine/interfaces.py b/lib/sqlalchemy/engine/interfaces.py index 8fa36f3cda..e1e1b3ba5b 100644 --- a/lib/sqlalchemy/engine/interfaces.py +++ b/lib/sqlalchemy/engine/interfaces.py @@ -581,8 +581,8 @@ class BindTyping(Enum): """Use the pep-249 setinputsizes method. This is only implemented for DBAPIs that support this method and for which - the SQLAlchemy dialect has the appropriate infrastructure for that - dialect set up. Current dialects include cx_Oracle as well as + the SQLAlchemy dialect has the appropriate infrastructure for that dialect + set up. Current dialects include python-oracledb, cx_Oracle as well as optional support for SQL Server using pyodbc. When using setinputsizes, dialects also have a means of only using the @@ -872,12 +872,12 @@ class Dialect(EventTarget): the statement multiple times for a series of batches when large numbers of rows are given. - The parameter is False for the default dialect, and is set to - True for SQLAlchemy internal dialects SQLite, MySQL/MariaDB, PostgreSQL, - SQL Server. It remains at False for Oracle, which provides native - "executemany with RETURNING" support and also does not support - ``supports_multivalues_insert``. For MySQL/MariaDB, those MySQL - dialects that don't support RETURNING will not report + The parameter is False for the default dialect, and is set to True for + SQLAlchemy internal dialects SQLite, MySQL/MariaDB, PostgreSQL, SQL Server. + It remains at False for Oracle Database, which provides native "executemany + with RETURNING" support and also does not support + ``supports_multivalues_insert``. For MySQL/MariaDB, those MySQL dialects + that don't support RETURNING will not report ``insert_executemany_returning`` as True. .. versionadded:: 2.0 @@ -1094,7 +1094,8 @@ class Dialect(EventTarget): established on a :class:`.Table` object which will be passed as "reflection options" when using :paramref:`.Table.autoload_with`. - Current example is "oracle_resolve_synonyms" in the Oracle dialect. + Current example is "oracle_resolve_synonyms" in the Oracle Database + dialects. """ diff --git a/lib/sqlalchemy/engine/reflection.py b/lib/sqlalchemy/engine/reflection.py index 58e3aa390f..a0d4a58f26 100644 --- a/lib/sqlalchemy/engine/reflection.py +++ b/lib/sqlalchemy/engine/reflection.py @@ -630,7 +630,7 @@ class Inspector(inspection.Inspectable["Inspector"]): r"""Return a list of temporary table names for the current bind. This method is unsupported by most dialects; currently - only Oracle, PostgreSQL and SQLite implements it. + only Oracle Database, PostgreSQL and SQLite implements it. :param \**kw: Additional keyword argument to pass to the dialect specific implementation. See the documentation of the dialect @@ -666,7 +666,7 @@ class Inspector(inspection.Inspectable["Inspector"]): given name was created. This currently includes some options that apply to MySQL and Oracle - tables. + Database tables. :param table_name: string name of the table. For special quoting, use :class:`.quoted_name`. diff --git a/lib/sqlalchemy/ext/compiler.py b/lib/sqlalchemy/ext/compiler.py index b870adce92..2408b97184 100644 --- a/lib/sqlalchemy/ext/compiler.py +++ b/lib/sqlalchemy/ext/compiler.py @@ -226,7 +226,7 @@ A synopsis is as follows: @compiles(coalesce, 'oracle') def compile(element, compiler, **kw): if len(element.clauses) > 2: - raise TypeError("coalesce only supports two arguments on Oracle") + raise TypeError("coalesce only supports two arguments on Oracle Database") return "nvl(%s)" % compiler.process(element.clauses, **kw) * :class:`.ExecutableDDLElement` - The root of all DDL expressions, diff --git a/lib/sqlalchemy/orm/context.py b/lib/sqlalchemy/orm/context.py index 4d11398bc7..6ac237f118 100644 --- a/lib/sqlalchemy/orm/context.py +++ b/lib/sqlalchemy/orm/context.py @@ -1579,8 +1579,8 @@ class ORMSelectCompileState(ORMCompileState, SelectState): ) statement._label_style = self.label_style - # Oracle however does not allow FOR UPDATE on the subquery, - # and the Oracle dialect ignores it, plus for PostgreSQL, MySQL + # Oracle Database however does not allow FOR UPDATE on the subquery, + # and the Oracle Database dialects ignore it, plus for PostgreSQL, MySQL # we expect that all elements of the row are locked, so also put it # on the outside (except in the case of PG when OF is used) if ( diff --git a/lib/sqlalchemy/sql/_elements_constructors.py b/lib/sqlalchemy/sql/_elements_constructors.py index bdc0534abe..55e92dd0c4 100644 --- a/lib/sqlalchemy/sql/_elements_constructors.py +++ b/lib/sqlalchemy/sql/_elements_constructors.py @@ -647,12 +647,12 @@ def bindparam( :param quote: True if this parameter name requires quoting and is not currently known as a SQLAlchemy reserved word; this currently - only applies to the Oracle backend, where bound names must + only applies to the Oracle Database backends, where bound names must sometimes be quoted. :param isoutparam: if True, the parameter should be treated like a stored procedure - "OUT" parameter. This applies to backends such as Oracle which + "OUT" parameter. This applies to backends such as Oracle Database which support OUT parameters. :param expanding: diff --git a/lib/sqlalchemy/sql/compiler.py b/lib/sqlalchemy/sql/compiler.py index 3eb412e6d7..d759a76c52 100644 --- a/lib/sqlalchemy/sql/compiler.py +++ b/lib/sqlalchemy/sql/compiler.py @@ -2348,7 +2348,7 @@ class SQLCompiler(Compiled): """Called when a SELECT statement has no froms, and no FROM clause is to be appended. - Gives Oracle a chance to tack on a ``FROM DUAL`` to the string output. + Gives Oracle Database a chance to tack on a ``FROM DUAL`` to the string output. """ return "" diff --git a/lib/sqlalchemy/sql/elements.py b/lib/sqlalchemy/sql/elements.py index 70c27ef5a8..7827831557 100644 --- a/lib/sqlalchemy/sql/elements.py +++ b/lib/sqlalchemy/sql/elements.py @@ -4326,7 +4326,7 @@ class WithinGroup(ColumnElement[_T]): ``rank()``, ``dense_rank()``, etc. It's supported only by certain database backends, such as PostgreSQL, - Oracle and MS SQL Server. + Oracle Database and MS SQL Server. The :class:`.WithinGroup` construct extracts its type from the method :meth:`.FunctionElement.within_group_type`. If this returns @@ -5204,7 +5204,7 @@ class quoted_name(util.MemoizedSlots, str): A :class:`.quoted_name` object with ``quote=True`` is also prevented from being modified in the case of a so-called "name normalize" option. Certain database backends, such as - Oracle, Firebird, and DB2 "normalize" case-insensitive names + Oracle Database, Firebird, and DB2 "normalize" case-insensitive names as uppercase. The SQLAlchemy dialects for these backends convert from SQLAlchemy's lower-case-means-insensitive convention to the upper-case-means-insensitive conventions of those backends. @@ -5225,11 +5225,11 @@ class quoted_name(util.MemoizedSlots, str): from sqlalchemy import inspect from sqlalchemy.sql import quoted_name - engine = create_engine("oracle+cx_oracle://some_dsn") + engine = create_engine("oracle+oracledb://some_dsn") print(inspect(engine).has_table(quoted_name("some_table", True))) - The above logic will run the "has table" logic against the Oracle backend, - passing the name exactly as ``"some_table"`` without converting to + The above logic will run the "has table" logic against the Oracle Database + backend, passing the name exactly as ``"some_table"`` without converting to upper case. .. versionchanged:: 1.2 The :class:`.quoted_name` construct is now diff --git a/lib/sqlalchemy/sql/operators.py b/lib/sqlalchemy/sql/operators.py index 65b94f32b5..c6af601856 100644 --- a/lib/sqlalchemy/sql/operators.py +++ b/lib/sqlalchemy/sql/operators.py @@ -1569,7 +1569,7 @@ class ColumnOperators(Operators): :class:`_mysql.match` - MySQL specific construct with additional features. - * Oracle - renders ``CONTAINS(x, y)`` + * Oracle Database - renders ``CONTAINS(x, y)`` * other backends may provide special implementations. * Backends without any special implementation will emit the operator as "MATCH". This is compatible with SQLite, for @@ -1597,7 +1597,7 @@ class ColumnOperators(Operators): Examples include: * PostgreSQL - renders ``x ~ y`` or ``x !~ y`` when negated. - * Oracle - renders ``REGEXP_LIKE(x, y)`` + * Oracle Database - renders ``REGEXP_LIKE(x, y)`` * SQLite - uses SQLite's ``REGEXP`` placeholder operator and calls into the Python ``re.match()`` builtin. * other backends may provide special implementations. @@ -1605,7 +1605,7 @@ class ColumnOperators(Operators): the operator as "REGEXP" or "NOT REGEXP". This is compatible with SQLite and MySQL, for example. - Regular expression support is currently implemented for Oracle, + Regular expression support is currently implemented for Oracle Database, PostgreSQL, MySQL and MariaDB. Partial support is available for SQLite. Support among third-party dialects may vary. @@ -1658,8 +1658,8 @@ class ColumnOperators(Operators): **not backend agnostic**. Regular expression replacement support is currently implemented for - Oracle, PostgreSQL, MySQL 8 or greater and MariaDB. Support among - third-party dialects may vary. + Oracle Database, PostgreSQL, MySQL 8 or greater and MariaDB. Support + among third-party dialects may vary. :param pattern: The regular expression pattern string or column clause. diff --git a/lib/sqlalchemy/sql/schema.py b/lib/sqlalchemy/sql/schema.py index 21c44d8170..f068453b1f 100644 --- a/lib/sqlalchemy/sql/schema.py +++ b/lib/sqlalchemy/sql/schema.py @@ -1546,7 +1546,7 @@ class Column(DialectKWArgs, SchemaItem, ColumnClause[_T]): unless they are a reserved word. Names with any number of upper case characters will be quoted and sent exactly. Note that this behavior applies even for databases which standardize upper - case names as case insensitive such as Oracle. + case names as case insensitive such as Oracle Database. The name field may be omitted at construction time and applied later, at any time before the Column is associated with a @@ -1618,8 +1618,8 @@ class Column(DialectKWArgs, SchemaItem, ColumnClause[_T]): will imply that database-specific keywords such as PostgreSQL ``SERIAL``, MySQL ``AUTO_INCREMENT``, or ``IDENTITY`` on SQL Server should also be rendered. Not every database backend has an - "implied" default generator available; for example the Oracle - backend always needs an explicit construct such as + "implied" default generator available; for example the Oracle Database + backends alway needs an explicit construct such as :class:`.Identity` to be included with a :class:`.Column` in order for the DDL rendered to include auto-generating constructs to also be produced in the database. @@ -1693,7 +1693,7 @@ class Column(DialectKWArgs, SchemaItem, ColumnClause[_T]): is not included as this is unnecessary and not recommended by the database vendor. See the section :ref:`sqlite_autoincrement` for more background. - * Oracle - The Oracle dialect has no default "autoincrement" + * Oracle Database - The Oracle Database dialects have no default "autoincrement" feature available at this time, instead the :class:`.Identity` construct is recommended to achieve this (the :class:`.Sequence` construct may also be used). @@ -1710,10 +1710,10 @@ class Column(DialectKWArgs, SchemaItem, ColumnClause[_T]): (see `https://www.python.org/dev/peps/pep-0249/#lastrowid `_) - * PostgreSQL, SQL Server, Oracle - use RETURNING or an equivalent + * PostgreSQL, SQL Server, Oracle Database - use RETURNING or an equivalent construct when rendering an INSERT statement, and then retrieving the newly generated primary key values after execution - * PostgreSQL, Oracle for :class:`_schema.Table` objects that + * PostgreSQL, Oracle Database for :class:`_schema.Table` objects that set :paramref:`_schema.Table.implicit_returning` to False - for a :class:`.Sequence` only, the :class:`.Sequence` is invoked explicitly before the INSERT statement takes place so that the @@ -3776,7 +3776,7 @@ class Sequence(HasSchemaAttr, IdentityOptions, DefaultGenerator): @util.deprecated_params( order=( "2.1", - "This parameter is supported only by Oracle, " + "This parameter is supported only by Oracle Database, " "use ``oracle_order`` instead.", ) ) @@ -3867,10 +3867,10 @@ class Sequence(HasSchemaAttr, IdentityOptions, DefaultGenerator): :param cache: optional integer value; number of future values in the sequence which are calculated in advance. Renders the CACHE keyword - understood by Oracle and PostgreSQL. + understood by Oracle Database and PostgreSQL. :param order: optional boolean value; if ``True``, renders the - ORDER keyword, understood by Oracle, indicating the sequence is + ORDER keyword, understood by Oracle Database, indicating the sequence is definitively ordered. May be necessary to provide deterministic ordering using Oracle RAC. @@ -6106,12 +6106,12 @@ class Identity(IdentityOptions, FetchedValue, SchemaItem): @util.deprecated_params( order=( "2.1", - "This parameter is supported only by Oracle, " + "This parameter is supported only by Oracle Database, " "use ``oracle_order`` instead.", ), on_null=( "2.1", - "This parameter is supported only by Oracle, " + "This parameter is supported only by Oracle Database, " "use ``oracle_on_null`` instead.", ), ) @@ -6159,7 +6159,7 @@ class Identity(IdentityOptions, FetchedValue, SchemaItem): :param on_null: Set to ``True`` to specify ON NULL in conjunction with a ``always=False`` identity column. This option is only supported on - some backends, like Oracle. + some backends, like Oracle Database. :param start: the starting index of the sequence. :param increment: the increment value of the sequence. diff --git a/lib/sqlalchemy/sql/selectable.py b/lib/sqlalchemy/sql/selectable.py index f4bc0986d0..ee6176d8fc 100644 --- a/lib/sqlalchemy/sql/selectable.py +++ b/lib/sqlalchemy/sql/selectable.py @@ -508,7 +508,7 @@ class HasHints: :meth:`_expression.Select.prefix_with` - generic SELECT prefixing which also can suit some database-specific HINT syntaxes such as - MySQL or Oracle optimizer hints + MySQL or Oracle Database optimizer hints """ return self._with_hint(None, text, dialect_name) @@ -530,7 +530,7 @@ class HasHints: **specific to a single table** to a statement, in a location that is **dialect-specific**. To add generic optimizer hints to the **beginning** of a statement ahead of the SELECT keyword such as - for MySQL or Oracle, use the :meth:`_expression.Select.prefix_with` + for MySQL or Oracle Database, use the :meth:`_expression.Select.prefix_with` method. To add optimizer hints to the **end** of a statement such as for PostgreSQL, use the :meth:`_expression.Select.with_statement_hint` method. @@ -542,7 +542,7 @@ class HasHints: ``selectable`` argument. The dialect implementation typically uses Python string substitution syntax with the token ``%(name)s`` to render the name of - the table or alias. E.g. when using Oracle, the + the table or alias. E.g. when using Oracle Database, the following:: select(mytable).\ @@ -554,7 +554,7 @@ class HasHints: The ``dialect_name`` option will limit the rendering of a particular hint to a particular backend. Such as, to add hints for both Oracle - and Sybase simultaneously:: + Database and Sybase simultaneously:: select(mytable).\ with_hint(mytable, "index(%(name)s ix_mytable)", 'oracle').\ @@ -566,7 +566,7 @@ class HasHints: :meth:`_expression.Select.prefix_with` - generic SELECT prefixing which also can suit some database-specific HINT syntaxes such as - MySQL or Oracle optimizer hints + MySQL or Oracle Database optimizer hints """ @@ -1041,7 +1041,7 @@ class NamedFromClause(FromClause): A :class:`_sql.TableValuedColumn` is a :class:`_sql.ColumnElement` that represents a complete row in a table. Support for this construct is backend dependent, and is supported in various forms by backends - such as PostgreSQL, Oracle and SQL Server. + such as PostgreSQL, Oracle Database and SQL Server. E.g.: @@ -1725,7 +1725,7 @@ class Alias(roles.DMLTableRole, FromClauseAlias): Represents an alias, as typically applied to any table or sub-select within a SQL statement using the ``AS`` keyword (or - without the keyword on certain databases such as Oracle). + without the keyword on certain databases such as Oracle Database). This object is constructed from the :func:`_expression.alias` module level function as well as the :meth:`_expression.FromClause.alias` @@ -3841,8 +3841,8 @@ class GenerativeSelect(SelectBase, Generative): stmt = select(table).with_for_update(nowait=True) - On a database like PostgreSQL or Oracle, the above would render a - statement like:: + On a database like PostgreSQL or Oracle Database, the above would + render a statement like:: SELECT table.a, table.b FROM table FOR UPDATE NOWAIT @@ -3857,7 +3857,7 @@ class GenerativeSelect(SelectBase, Generative): variants. :param nowait: boolean; will render ``FOR UPDATE NOWAIT`` on Oracle - and PostgreSQL dialects. + Database and PostgreSQL dialects. :param read: boolean; will render ``LOCK IN SHARE MODE`` on MySQL, ``FOR SHARE`` on PostgreSQL. On PostgreSQL, when combined with @@ -3866,12 +3866,12 @@ class GenerativeSelect(SelectBase, Generative): :param of: SQL expression or list of SQL expression elements, (typically :class:`_schema.Column` objects or a compatible expression, for some backends may also be a table expression) which will render - into a ``FOR UPDATE OF`` clause; supported by PostgreSQL, Oracle, some - MySQL versions and possibly others. May render as a table or as a - column depending on backend. + into a ``FOR UPDATE OF`` clause; supported by PostgreSQL, Oracle + Database, some MySQL versions and possibly others. May render as a + table or as a column depending on backend. - :param skip_locked: boolean, will render ``FOR UPDATE SKIP LOCKED`` - on Oracle and PostgreSQL dialects or ``FOR SHARE SKIP LOCKED`` if + :param skip_locked: boolean, will render ``FOR UPDATE SKIP LOCKED`` on + Oracle Databae and PostgreSQL dialects or ``FOR SHARE SKIP LOCKED`` if ``read=True`` is also specified. :param key_share: boolean, will render ``FOR NO KEY UPDATE``, @@ -4078,10 +4078,10 @@ class GenerativeSelect(SelectBase, Generative): """Return a new selectable with the given FETCH FIRST criterion applied. - This is a numeric value which usually renders as - ``FETCH {FIRST | NEXT} [ count ] {ROW | ROWS} {ONLY | WITH TIES}`` - expression in the resulting select. This functionality is - is currently implemented for Oracle, PostgreSQL, MSSQL. + This is a numeric value which usually renders as ``FETCH {FIRST | NEXT} + [ count ] {ROW | ROWS} {ONLY | WITH TIES}`` expression in the resulting + select. This functionality is is currently implemented for Oracle + Database, PostgreSQL, MSSQL. Use :meth:`_sql.GenerativeSelect.offset` to specify the offset. diff --git a/lib/sqlalchemy/sql/sqltypes.py b/lib/sqlalchemy/sql/sqltypes.py index bc2d898ab9..95d94a27de 100644 --- a/lib/sqlalchemy/sql/sqltypes.py +++ b/lib/sqlalchemy/sql/sqltypes.py @@ -275,8 +275,8 @@ class Unicode(String): The :class:`.Unicode` type is a :class:`.String` subclass that assumes input and output strings that may contain non-ASCII characters, and for some backends implies an underlying column type that is explicitly - supporting of non-ASCII data, such as ``NVARCHAR`` on Oracle and SQL - Server. This will impact the output of ``CREATE TABLE`` statements and + supporting of non-ASCII data, such as ``NVARCHAR`` on Oracle Database and + SQL Server. This will impact the output of ``CREATE TABLE`` statements and ``CAST`` functions at the dialect level. The character encoding used by the :class:`.Unicode` type that is used to @@ -307,7 +307,6 @@ class Unicode(String): :meth:`.DialectEvents.do_setinputsizes` - """ __visit_name__ = "unicode" @@ -635,16 +634,16 @@ class Float(Numeric[_N]): indicates a number of digits for the generic :class:`_sqltypes.Float` datatype. - .. note:: For the Oracle backend, the + .. note:: For the Oracle Database backend, the :paramref:`_sqltypes.Float.precision` parameter is not accepted - when rendering DDL, as Oracle does not support float precision + when rendering DDL, as Oracle Database does not support float precision specified as a number of decimal places. Instead, use the - Oracle-specific :class:`_oracle.FLOAT` datatype and specify the + Oracle Database-specific :class:`_oracle.FLOAT` datatype and specify the :paramref:`_oracle.FLOAT.binary_precision` parameter. This is new in version 2.0 of SQLAlchemy. To create a database agnostic :class:`_types.Float` that - separately specifies binary precision for Oracle, use + separately specifies binary precision for Oracle Database, use :meth:`_types.TypeEngine.with_variant` as follows:: from sqlalchemy import Column @@ -755,7 +754,7 @@ class DateTime( to make use of the :class:`_types.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. + TIMESTAMP datatype, such as Oracle Database. """ @@ -2031,10 +2030,9 @@ class _AbstractInterval(HasExpressionLookup, TypeEngine[dt.timedelta]): class Interval(Emulated, _AbstractInterval, TypeDecorator[dt.timedelta]): """A type for ``datetime.timedelta()`` objects. - The Interval type deals with ``datetime.timedelta`` objects. In - PostgreSQL and Oracle, the native ``INTERVAL`` type is used; for others, - the value is stored as a date which is relative to the "epoch" - (Jan. 1, 1970). + The Interval type deals with ``datetime.timedelta`` objects. In PostgreSQL + and Oracle Database, the native ``INTERVAL`` type is used; for others, the + value is stored as a date which is relative to the "epoch" (Jan. 1, 1970). Note that the ``Interval`` type does not currently provide date arithmetic operations on platforms which do not support interval types natively. Such @@ -2059,16 +2057,16 @@ class Interval(Emulated, _AbstractInterval, TypeDecorator[dt.timedelta]): :param native: when True, use the actual INTERVAL type provided by the database, if - supported (currently PostgreSQL, Oracle). + supported (currently PostgreSQL, Oracle Database). Otherwise, represent the interval data as an epoch value regardless. :param second_precision: For native interval types which support a "fractional seconds precision" parameter, - i.e. Oracle and PostgreSQL + i.e. Oracle Database and PostgreSQL :param day_precision: for native interval types which - support a "day precision" parameter, i.e. Oracle. + support a "day precision" parameter, i.e. Oracle Database. """ super().__init__() @@ -3324,8 +3322,8 @@ class BIGINT(BigInteger): class TIMESTAMP(DateTime): """The SQL TIMESTAMP type. - :class:`_types.TIMESTAMP` datatypes have support for timezone - storage on some backends, such as PostgreSQL and Oracle. Use the + :class:`_types.TIMESTAMP` datatypes have support for timezone storage on + some backends, such as PostgreSQL and Oracle Database. Use the :paramref:`~types.TIMESTAMP.timezone` argument in order to enable "TIMESTAMP WITH TIMEZONE" for these backends. @@ -3377,7 +3375,7 @@ class TEXT(Text): class CLOB(Text): """The CLOB type. - This type is found in Oracle and Informix. + This type is found in Oracle Database and Informix. """ __visit_name__ = "CLOB" diff --git a/reap_dbs.py b/reap_dbs.py index 81f9b8f26e..11a09ab67f 100644 --- a/reap_dbs.py +++ b/reap_dbs.py @@ -1,4 +1,4 @@ -"""Drop Oracle, SQL Server databases that are left over from a +"""Drop Oracle Database, SQL Server databases that are left over from a multiprocessing test run. Currently the cx_Oracle driver seems to sometimes not release a -- 2.47.3