.. changelog::
:version: 2.0.0b4
- :include_notes_from: unreleased_20
+ :released: December 5, 2022
+
+ .. change::
+ :tags: usecase, orm
+ :tickets: 8859
+
+ Added support custom user-defined types which extend the Python
+ ``enum.Enum`` base class to be resolved automatically
+ to SQLAlchemy :class:`.Enum` SQL types, when using the Annotated
+ Declarative Table feature. The feature is made possible through new
+ lookup features added to the ORM type map feature, and includes support
+ for changing the arguments of the :class:`.Enum` that's generated by
+ default as well as setting up specific ``enum.Enum`` types within
+ the map with specific arguments.
+
+ .. seealso::
+
+ :ref:`orm_declarative_mapped_column_enums`
+
+ .. change::
+ :tags: bug, typing
+ :tickets: 8783
+
+ Adjusted internal use of the Python ``enum.IntFlag`` class which changed
+ its behavioral contract in Python 3.11. This was not causing runtime
+ failures however caused typing runs to fail under Python 3.11.
+
+ .. change::
+ :tags: usecase, typing
+ :tickets: 8847
+
+ Added a new type :class:`.SQLColumnExpression` which may be indicated in
+ user code to represent any SQL column oriented expression, including both
+ those based on :class:`.ColumnElement` as well as on ORM
+ :class:`.QueryableAttribute`. This type is a real class, not an alias, so
+ can also be used as the foundation for other objects. An additional
+ ORM-specific subclass :class:`.SQLORMExpression` is also included.
+
+
+ .. change::
+ :tags: bug, typing
+ :tickets: 8667, 6810
+
+ The ``sqlalchemy.ext.mutable`` extension and ``sqlalchemy.ext.automap``
+ extensions are now fully pep-484 typed. Huge thanks to Gleb Kisenkov for
+ their efforts on this.
+
+
+
+ .. change::
+ :tags: bug, sql
+ :tickets: 8849
+
+ The approach to the ``numeric`` pep-249 paramstyle has been rewritten, and
+ is now fully supported, including by features such as "expanding IN" and
+ "insertmanyvalues". Parameter names may also be repeated in the source SQL
+ construct which will be correctly represented within the numeric format
+ using a single parameter. Introduced an additional numeric paramstyle
+ called ``numeric_dollar``, which is specifically what's used by the asyncpg
+ dialect; the paramstyle is equivalent to ``numeric`` except numeric
+ indicators are indicated by a dollar-sign rather than a colon. The asyncpg
+ dialect now uses ``numeric_dollar`` paramstyle directly, rather than
+ compiling to ``format`` style first.
+
+ The ``numeric`` and ``numeric_dollar`` paramstyles assume that the target
+ backend is capable of receiving the numeric parameters in any order,
+ and will match the given parameter values to the statement based on
+ matching their position (1-based) to the numeric indicator. This is the
+ normal behavior of "numeric" paramstyles, although it was observed that
+ the SQLite DBAPI implements a not-used "numeric" style that does not honor
+ parameter ordering.
+
+ .. change::
+ :tags: usecase, postgresql
+ :tickets: 8765
+
+ Complementing :ticket:`8690`, new comparison methods such as
+ :meth:`_postgresql.Range.adjacent_to`,
+ :meth:`_postgresql.Range.difference`, :meth:`_postgresql.Range.union`,
+ etc., were added to the PG-specific range objects, bringing them in par
+ with the standard operators implemented by the underlying
+ :attr:`_postgresql.AbstractRange.comparator_factory`.
+
+ In addition, the ``__bool__()`` method of the class has been corrected to
+ be consistent with the common Python containers behavior as well as how
+ other popular PostgreSQL drivers do: it now tells whether the range
+ instance is *not* empty, rather than the other way around.
+
+ Pull request courtesy Lele Gaifax.
+
+ .. change::
+ :tags: bug, sql
+ :tickets: 8770
+
+ Adjusted the rendering of ``RETURNING``, in particular when using
+ :class:`_sql.Insert`, such that it now renders columns using the same logic
+ as that of the :class:`.Select` construct to generate labels, which will
+ include disambiguating labels, as well as that a SQL function surrounding a
+ named column will be labeled using the column name itself. This establishes
+ better cross-compatibility when selecting rows from either :class:`.Select`
+ constructs or from DML statements that use :meth:`.UpdateBase.returning`. A
+ narrower scale change was also made for the 1.4 series that adjusted the
+ function label issue only.
+
+ .. change::
+ :tags: change, postgresql, asyncpg
+ :tickets: 8926
+
+ Changed the paramstyle used by asyncpg from ``format`` to
+ ``numeric_dollar``. This has two main benefits since it does not require
+ additional processing of the statement and allows for duplicate parameters
+ to be present in the statements.
+
+ .. change::
+ :tags: bug, orm
+ :tickets: 8888
+
+ Fixed issue where use of an unknown datatype within a :class:`.Mapped`
+ annotation for a column-based attribute would silently fail to map the
+ attribute, rather than reporting an exception; an informative exception
+ message is now raised.
+
+ .. change::
+ :tags: bug, orm
+ :tickets: 8777
+
+ Fixed a suite of issues involving :class:`.Mapped` use with dictionary
+ types, such as ``Mapped[dict[str, str] | None]``, would not be correctly
+ interpreted in Declarative ORM mappings. Support to correctly
+ "de-optionalize" this type including for lookup in ``type_annotation_map``
+ has been fixed.
+
+ .. change::
+ :tags: feature, orm
+ :tickets: 8822
+
+ Added a new parameter :paramref:`_orm.mapped_column.use_existing_column` to
+ accommodate the use case of a single-table inheritance mapping that uses
+ the pattern of more than one subclass indicating the same column to take
+ place on the superclass. This pattern was previously possible by using
+ :func:`_orm.declared_attr` in conjunction with locating the existing column
+ in the ``.__table__`` of the superclass, however is now updated to work
+ with :func:`_orm.mapped_column` as well as with pep-484 typing, in a
+ simple and succinct way.
+
+ .. seealso::
+
+ :ref:`orm_inheritance_column_conflicts`
+
+
+
+
+ .. change::
+ :tags: bug, mssql
+ :tickets: 8917
+
+ Fixed regression caused by the combination of :ticket:`8177`, re-enable
+ setinputsizes for SQL server unless fast_executemany + DBAPI executemany is
+ used for a statement, along with :ticket:`6047`, implement
+ "insertmanyvalues", which bypasses DBAPI executemany in place of a custom
+ DBAPI execute for INSERT statements. setinputsizes would incorrectly not be
+ used for a multiple parameter-set INSERT statement that used
+ "insertmanyvalues" if fast_executemany were turned on, as the check would
+ incorrectly assume this is a DBAPI executemany call. The "regression"
+ would then be that the "insertmanyvalues" statement format is apparently
+ slightly more sensitive to multiple rows that don't use the same types
+ for each row, so in such a case setinputsizes is especially needed.
+
+ The fix repairs the fast_executemany check so that it only disables
+ setinputsizes if true DBAPI executemany is to be used.
+
+ .. change::
+ :tags: bug, orm, performance
+ :tickets: 8796
+
+ Additional performance enhancements within ORM-enabled SQL statements,
+ specifically targeting callcounts within the construction of ORM
+ statements, using combinations of :func:`_orm.aliased` with
+ :func:`_sql.union` and similar "compound" constructs, in addition to direct
+ performance improvements to the ``corresponding_column()`` internal method
+ that is used heavily by the ORM by constructs like :func:`_orm.aliased` and
+ similar.
+
+
+ .. change::
+ :tags: bug, postgresql
+ :tickets: 8884
+
+ Added additional type-detection for the new PostgreSQL
+ :class:`_postgresql.Range` type, where previous cases that allowed the
+ psycopg2-native range objects to be received directly by the DBAPI without
+ SQLAlchemy intercepting them stopped working, as we now have our own value
+ object. The :class:`_postgresql.Range` object has been enhanced such that
+ SQLAlchemy Core detects it in otherwise ambiguous situations (such as
+ comparison to dates) and applies appropriate bind handlers. Pull request
+ courtesy Lele Gaifax.
+
+ .. change::
+ :tags: bug, orm
+ :tickets: 8880
+
+ 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
+ after dataclasses itself had replaced the ``Field`` object with the
+ class-level default value.
+
+ .. change::
+ :tags: usecase, orm extensions
+ :tickets: 8878
+
+ 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
+ arguments including :paramref:`.association_proxy.init` and
+ :paramref:`.association_proxy.default_factory`.
+
+ Documentation for association proxy has also been updated to use
+ "Annotated Declarative Table" forms within examples, including type
+ annotations used for :class:`.AssocationProxy` itself.
+
+
+ .. change::
+ :tags: bug, typing
+
+ Corrected typing support for the :paramref:`_orm.relationship.secondary`
+ argument which may also accept a callable (lambda) that returns a
+ :class:`.FromClause`.
+
+ .. change::
+ :tags: bug, orm, regression
+ :tickets: 8812
+
+ Fixed regression where flushing a mapped class that's mapped against a
+ subquery, such as a direct mapping or some forms of concrete table
+ inheritance, would fail if the :paramref:`_orm.Mapper.eager_defaults`
+ parameter were used.
+
+ .. change::
+ :tags: bug, schema
+ :tickets: 8925
+
+ Stricter rules are in place for appending of :class:`.Column` objects to
+ :class:`.Table` objects, both moving some previous deprecation warnings to
+ exceptions, and preventing some previous scenarios that would cause
+ duplicate columns to appear in tables, when
+ :paramref:`.Table.extend_existing` were set to ``True``, for both
+ programmatic :class:`.Table` construction as well as during reflection
+ operations.
+
+ See :ref:`change_8925` for a rundown of these changes.
+
+ .. seealso::
+
+ :ref:`change_8925`
+
+ .. change::
+ :tags: usecase, orm
+ :tickets: 8905
+
+ Added :paramref:`_orm.mapped_column.compare` parameter to relevant ORM
+ 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
+ Simon Schiele.
+
+ .. change::
+ :tags: sql, usecase
+ :tickets: 6289
+
+ Added :class:`_expression.ScalarValues` that can be used as a column
+ element allowing using :class:`_expression.Values` inside ``IN`` clauses
+ or in conjunction with ``ANY`` or ``ALL`` collection aggregates.
+ This new class is generated using the method
+ :meth:`_expression.Values.scalar_values`.
+ The :class:`_expression.Values` instance is now coerced to a
+ :class:`_expression.ScalarValues` when used in a ``IN`` or ``NOT IN``
+ operation.
+
+ .. change::
+ :tags: bug, orm
+ :tickets: 8853
+
+ Fixed regression in 2.0.0b3 caused by :ticket:`8759` where indicating the
+ :class:`.Mapped` name using a qualified name such as
+ ``sqlalchemy.orm.Mapped`` would fail to be recognized by Declarative as
+ indicating the :class:`.Mapped` construct.
+
+ .. change::
+ :tags: bug, typing
+ :tickets: 8842
+
+ Improved the typing for :class:`.sessionmaker` and
+ :class:`.async_sessionmaker`, so that the default type of their return value
+ will be :class:`.Session` or :class:`.AsyncSession`, without the need to
+ type this explicitly. Previously, Mypy would not automaticaly infer these
+ return types from its generic base.
+
+ As part of this change, arguments for :class:`.Session`,
+ :class:`.AsyncSession`, :class:`.sessionmaker` and
+ :class:`.async_sessionmaker` beyond the initial "bind" argument have been
+ made keyword-only, which includes parameters that have always been
+ documented as keyword arguments, such as :paramref:`.Session.autoflush`,
+ :paramref:`.Session.class_`, etc.
+
+ Pull request courtesy Sam Bull.
+
+
+ .. change::
+ :tags: bug, typing
+ :tickets: 8776
+
+ Fixed issue where passing a callbale function returning an iterable
+ of column elements to :paramref:`_orm.relationship.order_by` was
+ flagged as an error in type checkers.
.. changelog::
:version: 2.0.0b3