summaryrefslogtreecommitdiff
path: root/doc/build/changelog
diff options
context:
space:
mode:
Diffstat (limited to 'doc/build/changelog')
-rw-r--r--doc/build/changelog/changelog_14.rst51
-rw-r--r--doc/build/changelog/changelog_20.rst40
-rw-r--r--doc/build/changelog/migration_13.rst12
-rw-r--r--doc/build/changelog/migration_14.rst46
-rw-r--r--doc/build/changelog/migration_20.rst12
-rw-r--r--doc/build/changelog/whatsnew_20.rst26
6 files changed, 91 insertions, 96 deletions
diff --git a/doc/build/changelog/changelog_14.rst b/doc/build/changelog/changelog_14.rst
index 1e80c684c..6d78899fb 100644
--- a/doc/build/changelog/changelog_14.rst
+++ b/doc/build/changelog/changelog_14.rst
@@ -7,11 +7,6 @@ This document details individual issue-level changes made throughout
:ref:`migration_14_toplevel`.
-.. changelog_imports::
-
- .. include:: changelog_13.rst
- :start-line: 5
-
.. changelog::
:version: 1.4.48
@@ -995,7 +990,7 @@ This document details individual issue-level changes made throughout
.. seealso::
- :ref:`azure_synapse_ignore_no_transaction_on_rollback`
+ ref_azure_synapse_ignore_no_transaction_on_rollback
.. change::
:tags: bug, mypy
@@ -1832,7 +1827,7 @@ This document details individual issue-level changes made throughout
.. seealso::
- :ref:`postgresql_constraint_options`
+ ref_postgresql_constraint_options
.. change::
:tags: bug, orm, regression
@@ -1982,7 +1977,7 @@ This document details individual issue-level changes made throughout
.. seealso::
- :ref:`asyncio_events_run_async`
+ ref_asyncio_events_run_async
.. change::
@@ -3229,7 +3224,7 @@ This document details individual issue-level changes made throughout
.. seealso::
- :ref:`asyncmy`
+ ref_asyncmy
.. change::
:tags: bug, asyncio
@@ -4014,7 +4009,7 @@ This document details individual issue-level changes made throughout
.. seealso::
- :ref:`asyncio_scoped_session`
+ ref_asyncio_scoped_session
.. change::
:tags: usecase, mysql
@@ -5293,7 +5288,7 @@ This document details individual issue-level changes made throughout
.. seealso::
- :ref:`mypy_declarative_mixins`
+ ref_mypy_declarative_mixins
.. change::
@@ -5582,7 +5577,7 @@ This document details individual issue-level changes made throughout
.. seealso::
- :ref:`aiosqlite`
+ ref_aiosqlite
.. change::
:tags: bug, regression, orm, declarative
@@ -5632,7 +5627,7 @@ This document details individual issue-level changes made throughout
.. seealso::
- :ref:`pysqlcipher`
+ ref_pysqlcipher
.. change::
@@ -5746,7 +5741,7 @@ This document details individual issue-level changes made throughout
.. seealso::
- :ref:`orm_declarative_dataclasses_mixin`
+ ref_orm_declarative_dataclasses_mixin
.. change::
:tags: bug, sql, regression
@@ -5845,7 +5840,7 @@ This document details individual issue-level changes made throughout
.. seealso::
- :ref:`mssql_pyodbc_setinputsizes`
+ ref_mssql_pyodbc_setinputsizes
.. change::
:tags: bug, orm, regression
@@ -5947,7 +5942,7 @@ This document details individual issue-level changes made throughout
.. seealso::
- :ref:`mypy_toplevel`
+ ref_mypy_toplevel
.. change::
:tags: bug, sql
@@ -6402,7 +6397,7 @@ This document details individual issue-level changes made throughout
.. seealso::
- :ref:`orm_declarative_dataclasses_declarative_table`
+ ref_orm_declarative_dataclasses_declarative_table
.. change::
:tags: bug, sql
@@ -6510,7 +6505,7 @@ This document details individual issue-level changes made throughout
.. seealso::
- :ref:`asyncpg_prepared_statement_cache`
+ ref_asyncpg_prepared_statement_cache
.. change::
:tags: feature, mysql
@@ -6521,7 +6516,7 @@ This document details individual issue-level changes made throughout
.. seealso::
- :ref:`aiomysql`
+ ref_aiomysql
.. change::
:tags: bug, reflection
@@ -6605,7 +6600,7 @@ This document details individual issue-level changes made throughout
.. seealso::
- :ref:`sqlite_on_conflict_insert`
+ ref_sqlite_on_conflict_insert
.. change::
:tags: bug, asyncio
@@ -6701,7 +6696,7 @@ This document details individual issue-level changes made throughout
:ref:`mapper_automated_reflection_schemes` - in the ORM mapping documentation
- :ref:`automap_intercepting_columns` - in the :ref:`automap_toplevel` documentation
+ ref_automap_intercepting_columns - in the ref_automap_toplevel documentation
@@ -6792,7 +6787,7 @@ This document details individual issue-level changes made throughout
.. seealso::
- :ref:`metadata_reflection_dbagnostic_types` - example usage
+ ref_metadata_reflection_dbagnostic_types - example usage
.. change::
:tags: bug, sql
@@ -7523,13 +7518,13 @@ This document details individual issue-level changes made throughout
:tickets: 3414
SQLAlchemy now includes support for Python asyncio within both Core and
- ORM, using the included :ref:`asyncio extension <asyncio_toplevel>`. The
+ ORM, using the included ref_asyncio_toplevel. The
extension makes use of the `greenlet
<https://greenlet.readthedocs.io/en/latest/>`_ library in order to adapt
SQLAlchemy's sync-oriented internals such that an asyncio interface that
ultimately interacts with an asyncio database adapter is now feasible. The
single driver supported at the moment is the
- :ref:`dialect-postgresql-asyncpg` driver for PostgreSQL.
+ ref_dialect-postgresql-asyncpg driver for PostgreSQL.
.. seealso::
@@ -7663,7 +7658,7 @@ This document details individual issue-level changes made throughout
Microsoft SQL Server. This removes the deprecated feature of using
:class:`.Sequence` objects to manipulate IDENTITY characteristics which
should now be performed using ``mssql_identity_start`` and
- ``mssql_identity_increment`` as documented at :ref:`mssql_identity`. The
+ ``mssql_identity_increment`` as documented at ref_mssql_identity. The
change includes a new parameter :paramref:`.Sequence.data_type` to
accommodate SQL Server's choice of datatype, which for that backend
includes INTEGER, BIGINT, and DECIMAL(n, 0). The default starting value
@@ -7814,7 +7809,7 @@ This document details individual issue-level changes made throughout
.. seealso::
- :ref:`oracle_max_identifier_lengths` - in the Oracle dialect documentation
+ ref_oracle_max_identifier_lengths - in the Oracle dialect documentation
.. change::
@@ -8284,7 +8279,7 @@ This document details individual issue-level changes made throughout
.. seealso::
- :ref:`postgresql_readonly_deferrable`
+ ref_postgresql_readonly_deferrable
.. change::
:tags: mysql, feature
@@ -8549,7 +8544,7 @@ This document details individual issue-level changes made throughout
Remove deprecated method ``Session.prune`` and parameter
``Session.weak_identity_map``. See the recipe at
- :ref:`session_referencing_behavior` for an event-based approach to
+ ref_session_referencing_behavior for an event-based approach to
maintaining strong identity references.
This change also removes the class ``StrongInstanceDict``.
diff --git a/doc/build/changelog/changelog_20.rst b/doc/build/changelog/changelog_20.rst
index f6ec81c15..f254d4542 100644
--- a/doc/build/changelog/changelog_20.rst
+++ b/doc/build/changelog/changelog_20.rst
@@ -109,7 +109,7 @@
.. seealso::
- :ref:`asyncpg_prepared_statement_name`
+ ref_asyncpg_prepared_statement_name
.. change::
:tags: typing, bug
@@ -347,7 +347,7 @@
:ref:`error_dcmx` - background on rationale
- :ref:`orm_declarative_dc_mixins`
+ ref_orm_declarative_dc_mixins
.. change::
:tags: bug, postgresql
@@ -625,7 +625,7 @@
SQLAlchemy now computes rowcount for a RETURNING statement in this specific
case by counting the rows returned, rather than relying upon
``cursor.rowcount``. In particular, the ORM versioned rows use case
- (documented at :ref:`mapper_version_counter`) should now be fully
+ (documented at ref_mapper_version_counter) should now be fully
supported with the SQL Server pyodbc dialect.
@@ -829,7 +829,7 @@
:tags: usecase, typing
:tickets: 9321
- Improved the typing support for the :ref:`hybrids_toplevel`
+ Improved the typing support for the ref_hybrids_toplevel
extension, updated all documentation to use ORM Annotated Declarative
mappings, and added a new modifier called :attr:`.hybrid_property.inplace`.
This modifier provides a way to alter the state of a :class:`.hybrid_property`
@@ -845,7 +845,7 @@
.. seealso::
- :ref:`hybrid_pep484_naming`
+ ref_hybrid_pep484_naming
.. change::
:tags: bug, orm
@@ -885,7 +885,7 @@
:tickets: 9295
Adjusted the behavior of the ``thick_mode`` parameter for the
- :ref:`oracledb` dialect to correctly accept ``False`` as a value.
+ ref_oracledb dialect to correctly accept ``False`` as a value.
Previously, only ``None`` would indicate that thick mode should be
disabled.
@@ -936,7 +936,7 @@
.. seealso::
- :ref:`dataclasses_pydantic`
+ ref_dataclasses_pydantic
.. changelog::
@@ -1144,7 +1144,7 @@
:class:`_orm.Mapper` object is created within the class creation process,
there was no documented means of running code at this point. The change
is to immediately benefit custom mapping schemes such as that
- of the :ref:`examples_versioned_history` example, which generate additional
+ of the ref_examples_versioned_history example, which generate additional
mappers and tables in response to the creation of mapped classes.
@@ -1174,7 +1174,7 @@
:tags: bug, examples
:tickets: 9220
- Reworked the :ref:`examples_versioned_history` to work with
+ Reworked the ref_examples_versioned_history to work with
version 2.0, while at the same time improving the overall working of
this example to use newer APIs, including a newly added hook
:meth:`_orm.MapperEvents.after_mapper_constructed`.
@@ -1406,7 +1406,7 @@
.. seealso::
- :ref:`automap_by_module` - illustrates use of both techniques at once.
+ ref_automap_by_module - illustrates use of both techniques at once.
.. change::
:tags: orm, bug
@@ -1520,7 +1520,7 @@
.. seealso::
- :ref:`mssql_comment_support`
+ ref_mssql_comment_support
.. changelog::
@@ -1937,7 +1937,7 @@
.. seealso::
- :ref:`orm_declarative_native_dataclasses_non_mapped_fields`
+ ref_orm_declarative_native_dataclasses_non_mapped_fields
.. change::
@@ -2172,7 +2172,7 @@
:tags: bug, orm
:tickets: 8880
- Fixed bug in :ref:`orm_declarative_native_dataclasses` feature where using
+ Fixed bug in ref_orm_declarative_native_dataclasses feature where using
plain dataclass fields with the ``__allow_unmapped__`` directive in a
mapping would not create a dataclass with the correct class-level state for
those fields, copying the raw ``Field`` object to the class inappropriately
@@ -2186,7 +2186,7 @@
Added support for the :func:`.association_proxy` extension function to
take part within Python ``dataclasses`` configuration, when using
the native dataclasses feature described at
- :ref:`orm_declarative_native_dataclasses`. Included are attribute-level
+ ref_orm_declarative_native_dataclasses. Included are attribute-level
arguments including :paramref:`.association_proxy.init` and
:paramref:`.association_proxy.default_factory`.
@@ -2237,7 +2237,7 @@
attribute constructs including :func:`_orm.mapped_column`,
:func:`_orm.relationship` etc. to provide for the Python dataclasses
``compare`` parameter on ``field()``, when using the
- :ref:`orm_declarative_native_dataclasses` feature. Pull request courtesy
+ ref_orm_declarative_native_dataclasses feature. Pull request courtesy
Simon Schiele.
.. change::
@@ -3005,7 +3005,7 @@
.. seealso::
- :ref:`sqlite_include_internal`
+ ref_sqlite_include_internal
.. change::
:tags: feature, postgresql
@@ -3039,7 +3039,7 @@
:ref:`ticket_8054`
- :ref:`oracledb`
+ ref_oracledb
.. change::
:tags: bug, engine
@@ -3197,7 +3197,7 @@
:ref:`ticket_6842`
- :ref:`postgresql_psycopg`
+ ref_postgresql_psycopg
@@ -3231,7 +3231,7 @@
Additionally, classes mapped by :class:`_orm.composite` now support
ordering comparison operations, e.g. ``<``, ``>=``, etc.
- See the new documentation at :ref:`mapper_composite` for examples.
+ See the new documentation at ref_mapper_composite for examples.
.. change::
:tags: engine, bug
@@ -4005,7 +4005,7 @@
``'value'``. For normal bound value handling, the :class:`_types.Unicode`
datatype also may have implications for passing values to the DBAPI, again
in the case of SQL Server, the pyodbc driver supports the use of
- :ref:`setinputsizes mode <mssql_pyodbc_setinputsizes>` which will handle
+ ref_mssql_pyodbc_setinputsizes which will handle
:class:`_types.String` versus :class:`_types.Unicode` differently.
diff --git a/doc/build/changelog/migration_13.rst b/doc/build/changelog/migration_13.rst
index f7ce653f4..7249b3c21 100644
--- a/doc/build/changelog/migration_13.rst
+++ b/doc/build/changelog/migration_13.rst
@@ -1228,7 +1228,7 @@ the ON clause of the SQL join is expressed in terms of a SQL function.
Expanding IN feature now supports empty lists
---------------------------------------------
-The "expanding IN" feature introduced in version 1.2 at :ref:`change_3953` now
+The "expanding IN" feature introduced in version 1.2 at ref_change_3953 now
supports empty lists passed to the :meth:`.ColumnOperators.in_` operator. The implementation
for an empty list will produce an "empty set" expression that is specific to a target
backend, such as "SELECT CAST(NULL AS INTEGER) WHERE 1!=1" for PostgreSQL,
@@ -1352,7 +1352,7 @@ Coercion of string SQL fragments to text() fully removed
---------------------------------------------------------
The warnings that were first added in version 1.0, described at
-:ref:`migration_2992`, have now been converted into exceptions. Continued
+ref_migration_2992, have now been converted into exceptions. Continued
concerns have been raised regarding the automatic coercion of string fragments
passed to methods like :meth:`_query.Query.filter` and :meth:`_expression.Select.order_by` being
converted to :func:`_expression.text` constructs, even though this has emitted a warning.
@@ -1554,7 +1554,7 @@ can now be explicitly ordered by passing a list of 2-tuples::
.. seealso::
- :ref:`mysql_insert_on_duplicate_key_update`
+ ref_mysql_insert_on_duplicate_key_update
Dialect Improvements and Changes - SQLite
=============================================
@@ -1611,7 +1611,7 @@ The above table would render in a CREATE TABLE statement as:
.. seealso::
- :ref:`sqlite_on_conflict_ddl`
+ ref_sqlite_on_conflict_ddl
:ticket:`4360`
@@ -1708,7 +1708,7 @@ Pass it via :func:`_sa.create_engine`::
.. seealso::
- :ref:`mssql_pyodbc_fastexecutemany`
+ ref_mssql_pyodbc_fastexecutemany
:ticket:`4158`
@@ -1758,7 +1758,7 @@ primary key column::
.. seealso::
- :ref:`mssql_identity`
+ ref_mssql_identity
:ticket:`4362`
diff --git a/doc/build/changelog/migration_14.rst b/doc/build/changelog/migration_14.rst
index ac6cb6a53..4e94c2919 100644
--- a/doc/build/changelog/migration_14.rst
+++ b/doc/build/changelog/migration_14.rst
@@ -174,7 +174,7 @@ construction routines that must be built up each time an ORM query seeks to run
and construct ORM objects from result sets.
To introduce the general idea of the feature, given code from the
-:ref:`examples_performance` suite as follows, which will invoke
+ref_examples_performance suite as follows, which will invoke
a very simple query "n" times, for a default value of n=10000. The
query returns only a single row, as the overhead we are looking to decrease
is that of **many small queries**. The optimization is not as significant
@@ -287,7 +287,7 @@ In addition, The :func:`_declarative.instrument_declarative` function is
deprecated, superseded by :meth:`_orm.registry.map_declaratively`. The
:class:`_declarative.ConcreteBase`, :class:`_declarative.AbstractConcreteBase`,
and :class:`_declarative.DeferredReflection` classes remain as extensions in the
-:ref:`declarative_toplevel` package.
+ref_declarative_toplevel package.
Mapping styles have now been organized such that they all extend from
the :class:`_orm.registry` object, and fall into these categories:
@@ -299,10 +299,10 @@ the :class:`_orm.registry` object, and fall into these categories:
* Using :meth:`_orm.registry.mapped` Declarative Decorator
* Declarative Table
* Imperative Table (Hybrid)
- * :ref:`orm_declarative_dataclasses`
+ * ref_orm_declarative_dataclasses
* :ref:`Imperative (a.k.a. "classical" mapping) <orm_imperative_mapping>`
* Using :meth:`_orm.registry.map_imperatively`
- * :ref:`orm_imperative_dataclasses`
+ * ref_orm_imperative_dataclasses
The existing classical mapping function ``sqlalchemy.orm.mapper()`` remains,
however it is deprecated to call upon ``sqlalchemy.orm.mapper()`` directly; the
@@ -351,9 +351,9 @@ attribute systems can now interoperate with Declarative mappings as well.
.. seealso::
- :ref:`orm_declarative_dataclasses`
+ ref_orm_declarative_dataclasses
- :ref:`orm_imperative_dataclasses`
+ ref_orm_imperative_dataclasses
:ticket:`5027`
@@ -373,7 +373,7 @@ usage as well as :class:`_orm.Session` for ORM use, using the
the initial releases of SQLAlchemy 1.4. This is super new stuff that uses
some previously unfamiliar programming techniques.
-The initial database API supported is the :ref:`dialect-postgresql-asyncpg`
+The initial database API supported is the ref_dialect-postgresql-asyncpg
asyncio driver for PostgreSQL.
The internal features of SQLAlchemy are fully integrated by making use of
@@ -423,7 +423,7 @@ tradition, the new API provides a **strictly optional
feature** such that applications that wish to make use of such ORM features
can opt to organize database-related code into functions which can then be
run within greenlets using the :meth:`_asyncio.AsyncSession.run_sync`
-method. See the ``greenlet_orm.py`` example at :ref:`examples_asyncio`
+method. See the ``greenlet_orm.py`` example at ref_examples_asyncio
for a demonstration.
Support for asynchronous cursors is also provided using new methods
@@ -438,9 +438,9 @@ in traditional SQLAlchemy.
.. seealso::
- :ref:`asyncio_toplevel`
+ ref_asyncio_toplevel
- :ref:`examples_asyncio`
+ ref_examples_asyncio
@@ -553,7 +553,7 @@ is established as the implementation.
:meth:`_sql.ColumnOperators.regexp_replace`
- :ref:`pysqlite_regexp` - SQLite implementation notes
+ ref_pysqlite_regexp - SQLite implementation notes
:ticket:`1390`
@@ -1026,7 +1026,7 @@ structural specification, lists are used for data specification**.
All IN expressions render parameters for each value in the list on the fly (e.g. expanding parameters)
------------------------------------------------------------------------------------------------------
-The "expanding IN" feature, first introduced in :ref:`change_3953`, has matured
+The "expanding IN" feature, first introduced in ref_change_3953, has matured
enough such that it is clearly superior to the previous method of rendering IN
expressions. As the approach was improved to handle empty lists of values, it
is now the only means that Core / ORM will use to render lists of IN
@@ -1043,7 +1043,7 @@ their parameters, nor could the parameter dictionary be fully used for
statements that included IN expressions generally.
In order to service the "baked query" feature described at
-:ref:`baked_toplevel`, a cacheable version of IN was needed, which is what
+ref_baked_toplevel, a cacheable version of IN was needed, which is what
brought about the "expanding IN" feature. In contrast to the existing behavior
whereby the parameter list is expanded at statement construction time into
individual :class:`.BindParameter` objects, the feature instead uses a single
@@ -1114,7 +1114,7 @@ introduced in version 1.3 and is described at :ref:`change_4271`. The
:paramref:`_sa.create_engine.empty_in_strategy` parameter, introduced in version
1.2 as a means for migrating for how this case was treated for the previous IN
system, is now deprecated and this flag no longer has an effect; as described
-in :ref:`change_3907`, this flag allowed a dialect to switch between the
+in ref_change_3907, this flag allowed a dialect to switch between the
original system of comparing a column against itself, which turned out to be a
huge performance issue, and a newer system of comparing "1 != 1" in
order to produce a "false" expression. The 1.3 introduced behavior which
@@ -1941,7 +1941,7 @@ rather than invoking the same statement repeatedly, as psycopg2 lacks the abilit
to PREPARE the statement ahead of time as would normally be expected for this
approach to be performant.
-SQLAlchemy includes a :ref:`performance suite <examples_performance>` within
+SQLAlchemy includes a ref_examples_performance within
its examples, where we can compare the times generated for the "batch_inserts"
runner against 1.3 and 1.4, revealing a 3x-5x speedup for most flavors
of batch insert:
@@ -1993,7 +1993,7 @@ The ultimate INSERT statement can be seen by enabling statement logging on the P
The feature batches rows into groups of 1000 by default which can be affected
using the ``executemany_values_page_size`` argument documented at
-:ref:`psycopg2_executemany_mode`.
+ref_psycopg2_executemany_mode.
:ticket:`5263`
@@ -2572,7 +2572,7 @@ in the value of the ``name`` attribute. Since this is a SQL NULL, the ORM
would skip including these values within an INSERT so that SQL-level defaults
take place, if any, else the value defaults to NULL on the database side.
-In version 1.0 as part of :ref:`migration_3061`, this behavior was refined so
+In version 1.0 as part of ref_migration_3061, this behavior was refined so
that the ``None`` value was no longer populated into ``__dict__``, only
returned. Besides removing the mutating side effect of a getter operation,
this change also made it possible to set columns that did have server defaults
@@ -2969,7 +2969,7 @@ It also occurs beyond the cache boundary so that the INSERT statement may
be cached before the VALUES are rendered.
A quick test of the ``execute_values()`` approach using the
-``bulk_inserts.py`` script in the :ref:`examples_performance` example
+``bulk_inserts.py`` script in the ref_examples_performance example
suite reveals an approximate **fivefold performance increase**:
.. sourcecode:: text
@@ -2983,7 +2983,7 @@ suite reveals an approximate **fivefold performance increase**:
test_core_insert : A single Core INSERT construct inserting mappings in bulk. (100000 iterations); total time 0.944007 sec
Support for the "batch" extension was added in version 1.2 in
-:ref:`change_4109`, and enhanced to include support for the ``execute_values``
+ref_change_4109, and enhanced to include support for the ``execute_values``
extension in 1.3 in :ticket:`4623`. In 1.4 the ``execute_values`` extension is
now being turned on by default for INSERT statements; the "batch" extension
for UPDATE and DELETE remains off by default.
@@ -3035,7 +3035,7 @@ with the following changes:
.. seealso::
- :ref:`psycopg2_executemany_mode`
+ ref_psycopg2_executemany_mode
:ticket:`5401`
@@ -3051,7 +3051,7 @@ versions prior to 3.7.16, released in 2013. It is not expected that
any modern Python versions rely upon this limitation.
The behavior was first introduced in 0.9 and was part of the larger change of
-allowing for right nested joins as described at :ref:`feature_joins_09`.
+allowing for right nested joins as described at ref_feature_joins_09.
However the SQLite workaround produced many regressions in the 2013-2014
period due to its complexity. In 2016, the dialect was modified so that the
join rewriting logic would only occur for SQLite versions prior to 3.7.16 after
@@ -3114,7 +3114,7 @@ was not created.
.. seealso::
- :ref:`defaults_sequences`
+ ref_defaults_sequences
:ticket:`4976`
@@ -3139,7 +3139,7 @@ parameters should be used; see the MSSQL dialect documentation linked below.
.. seealso::
- :ref:`mssql_identity`
+ ref_mssql_identity
:ticket:`4235`
diff --git a/doc/build/changelog/migration_20.rst b/doc/build/changelog/migration_20.rst
index 1fe47b7ac..522fb87b1 100644
--- a/doc/build/changelog/migration_20.rst
+++ b/doc/build/changelog/migration_20.rst
@@ -458,7 +458,7 @@ of the :class:`_orm.Mapped` generic container. Annotations which don't use
:class:`_orm.Mapped` which link to constructs such as :func:`_orm.relationship`
will raise errors in Python, as they suggest mis-configurations.
-SQLAlchemy applications that use the :ref:`Mypy plugin <mypy_toplevel>` with
+SQLAlchemy applications that use the ref_mypy_toplevel with
explicit annotations that don't use :class:`_orm.Mapped` in their annotations
are subject to these errors, as would occur in the example below::
@@ -1298,8 +1298,8 @@ has always allowed this style using so-called
remove the base class requirement, a first class :ref:`decorator
<declarative_config_toplevel>` form has been added.
-As yet another separate but related enhancement, support for :ref:`Python
-dataclasses <orm_declarative_dataclasses>` is added as well to both
+As yet another separate but related enhancement, support for Python
+dataclasses is added as well to both
declarative decorator and classical mapping forms.
.. seealso::
@@ -1524,7 +1524,7 @@ following the table, and may include additional notes not summarized here.
)
# or
-
+
session.scalar(
select(func.count(User.id))
)
@@ -2163,7 +2163,7 @@ and should be preferred.
**Synopsis**
The ``lazy="dynamic"`` relationship loader strategy, discussed at
-:ref:`dynamic_relationship`, makes use of the :class:`_query.Query` object
+ref_dynamic_relationship, makes use of the :class:`_query.Query` object
which is legacy in 2.0. The "dynamic" relationship is not directly compatible
with asyncio without workarounds, and additionally it does not fulfill its
original purpose of preventing iteration of large collections as it has several
@@ -2249,7 +2249,7 @@ new feature is as :ref:`change_7123`.
:ref:`change_7123`
- :ref:`write_only_relationship`
+ ref_write_only_relationship
.. _migration_20_session_autocommit:
diff --git a/doc/build/changelog/whatsnew_20.rst b/doc/build/changelog/whatsnew_20.rst
index 366c9c0ff..524b40a87 100644
--- a/doc/build/changelog/whatsnew_20.rst
+++ b/doc/build/changelog/whatsnew_20.rst
@@ -371,7 +371,7 @@ ORM Declarative Models
~~~~~~~~~~~~~~~~~~~~~~
SQLAlchemy 1.4 introduced the first SQLAlchemy-native ORM typing support
-using a combination of sqlalchemy2-stubs_ and the :ref:`Mypy Plugin <mypy_toplevel>`.
+using a combination of sqlalchemy2-stubs_ and the ref_mypy_toplevel.
In SQLAlchemy 2.0, the Mypy plugin **remains available, and has been updated
to work with SQLAlchemy 2.0's typing system**. However, it should now be
considered **deprecated**, as applications now have a straightforward path to adopting the
@@ -731,7 +731,7 @@ and :class:`_engine.Row` objects::
Using Legacy Mypy-Typed Models
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-SQLAlchemy applications that use the :ref:`Mypy plugin <mypy_toplevel>` with
+SQLAlchemy applications that use the ref_mypy_toplevel with
explicit annotations that don't use :class:`_orm.Mapped` in their annotations
are subject to errors under the new system, as such annotations are flagged as
errors when using constructs such as :func:`_orm.relationship`.
@@ -848,7 +848,7 @@ positional arguments as configured::
.. seealso::
- :ref:`orm_declarative_native_dataclasses`
+ ref_orm_declarative_native_dataclasses
.. _change_6047:
@@ -910,7 +910,7 @@ and are still improved by the "insertmanyvalues" approach.
Benchmarks
~~~~~~~~~~
-SQLAlchemy includes a :ref:`Performance Suite <examples_performance>` within
+SQLAlchemy includes a ref_examples_performance within
the ``examples/`` directory, where we can make use of the ``bulk_insert``
suite to benchmark INSERTs of many rows using both Core and ORM in different
ways.
@@ -1271,11 +1271,11 @@ using :term:`2.0 style` to load the desired objects in an explicit way::
The :class:`_orm.WriteOnlyCollection` also integrates with the new
:ref:`ORM bulk dml <change_8360>` features, including support for bulk INSERT
and UPDATE/DELETE with WHERE criteria, all including RETURNING support as
-well. See the complete documentation at :ref:`write_only_relationship`.
+well. See the complete documentation at ref_write_only_relationship.
.. seealso::
- :ref:`write_only_relationship`
+ ref_write_only_relationship
New pep-484 / type annotated mapping support for Dynamic Relationships
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -1323,7 +1323,7 @@ as ``AccountTransaction``.
.. seealso::
- :ref:`dynamic_relationship`
+ ref_dynamic_relationship
:ticket:`7123`
@@ -1392,7 +1392,7 @@ Major Architectural, Performance and API Enhancements for Database Reflection
-----------------------------------------------------------------------------
The internal system by which :class:`.Table` objects and their components are
-:ref:`reflected <metadata_reflection>` has been completely rearchitected to
+ref_metadata_reflection has been completely rearchitected to
allow high performance bulk reflection of thousands of tables at once for
participating dialects. Currently, the **PostgreSQL** and **Oracle** dialects
participate in the new architecture, where the PostgreSQL dialect can now
@@ -1504,7 +1504,7 @@ automatically.
.. seealso::
- :ref:`postgresql_psycopg`
+ ref_postgresql_psycopg
.. _ticket_8054:
@@ -1517,7 +1517,7 @@ DBAPI, which is the renamed, new major release of the popular cx_Oracle driver.
.. seealso::
- :ref:`oracledb`
+ ref_oracledb
.. _ticket_7631:
@@ -2195,7 +2195,7 @@ customizable via the :paramref:`_sa.create_engine.poolclass` parameter.
.. seealso::
- :ref:`pysqlite_threading_pooling`
+ ref_pysqlite_threading_pooling
:ticket:`7490`
@@ -2286,12 +2286,12 @@ All PostgreSQL search functions and operators are available through use of
:data:`.func` to generate PostgreSQL-specific functions and
:meth:`.Operators.bool_op` (a boolean-typed version of :meth:`.Operators.op`)
to generate arbitrary operators, in the same manner as they are available
-in previous versions. See the examples at :ref:`postgresql_match`.
+in previous versions. See the examples at ref_postgresql_match.
Existing SQLAlchemy projects that make use of PG-specific directives within
:meth:`.Operators.match` should make use of ``func.to_tsquery()`` directly.
To render SQL in exactly the same form as would be present
-in 1.4, see the version note at :ref:`postgresql_simple_match`.
+in 1.4, see the version note at ref_postgresql_simple_match.
View Lorry Controller Status