:versions: 2.0.0b4
Fixed issues in :func:`_orm.with_expression` where expressions that were
- composed of columns within a subquery being SELECTed from, or when using
- ``.from_statement()``, would not render correct SQL **if** the expression
+ composed of columns that were referenced from the enclosing SELECT would
+ not render correct SQL in some contexts, in the case where the expression
had a label name that matched the attribute which used
:func:`_orm.query_expression`, even when :func:`_orm.query_expression` had
no default expression. For the moment, if the :func:`_orm.query_expression`
- **does** have a default expression, that label name is still used for that
- default, and an additional label with the same name will be ignored.
- Overall, this case is pretty thorny so further adjustments might be
- warranted.
+ does have a default expression, that label name is still used for that
+ default, and an additional label with the same name will continue to be
+ ignored. Overall, this case is pretty thorny so further adjustments might
+ be warranted.
:tickets: 6289
Added :class:`_expression.ScalarValues` that can be used as a column
- element allowing using :class:`_expression.Values` inside IN clauses
+ 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`.
.. change::
:tags: bug, typing
- :tickets: 8667
+ :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.
+
- The ``sqlalchemy.ext.mutable`` extension is now fully pep-484 typed. Huge
- thanks to Gleb Kisenkov for their efforts on this.
:tags: bug, sql
:tickets: 8770
- The RETURNING clause now renders columns using the routine as that of the
- :class:`.Select` 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 is a more comprehensive change
- than a similar one made for the 1.4 series that adjusted the function label
- issue only.
+ 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: bug, orm
+ :tags: bug, typing
:tickets: 8776
Fixed issue where passing a callbale function returning an iterable
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.
+ "de-optionalize" this type including for lookup in ``type_annotation_map``
+ has been fixed.
:tags: bug, typing
:tickets: 8783
- Adjusted internal use of the Python ``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.
+ 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.
:tickets: 8842
Improved the typing for :class:`.sessionmaker` and
- :class:`.asyncsessionmaker`, so that the default type of their return value
+ :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:`.asyncsessionmaker` beyond the initial "bind" argument have been
+ :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.
:tags: bug, sql
:tickets: 8849
- Reworked how numeric paramstyle behavers, in particular, fixed insertmany
- behaviour that prior to this was non functional; added support for repeated
- parameter without duplicating them like in other positional dialects;
- introduced new numeric paramstyle called ``numeric_dollar`` that can be
- used to render statements that use the PostgreSQL placeholder style (
- i.e. ``$1, $2, $3``).
- This change requires that the dialect supports out of order placehoders,
- that may be used used in the statements, in particular when using
- insert-many values with statement that have parameters in the returning
- clause.
+ 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.
:tags: bug, orm
:tickets: 8880
- Fixed bug in dataclass mapping feature where using plain dataclass fields
- 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.
+ 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: asyncpg
+ :tags: change, postgresql, asyncpg
:tickets: 8926
Changed the paramstyle used by asyncpg from ``format`` to
projects / thirdparty / sqlalchemy / sqlalchemy.git / commitdiff
