:released: January 22, 2020

.. change::

:tags: bug, postgresql

:tickets: 5039

Fixed issue where the PostgreSQL dialect would fail to parse a reflected

CHECK constraint that was a boolean-valued function (as opposed to a

boolean-valued expression).

.. change::

:tags: bug, ext

:tickets: 5086

Fixed bug in sqlalchemy.ext.serializer where a unique

:class:`.BindParameter` object could conflict with itself if it were

present in the mapping itself, as well as the filter condition of the

query, as one side would be used against the non-deserialized version and

the other side would use the deserialized version. Logic is added to

:class:`.BindParameter` similar to its "clone" method which will uniquify

the parameter name upon deserialize so that it doesn't conflict with its

original.

.. change::

:tags: usecase, sql

:tickets: 5079

A function created using :class:`.GenericFunction` can now specify that the

name of the function should be rendered with or without quotes by assigning

the :class:`.quoted_name` construct to the .name element of the object.

Prior to 1.3.4, quoting was never applied to function names, and some

quoting was introduced in :ticket:`4467` but no means to force quoting for

a mixed case name was available. Additionally, the :class:`.quoted_name`

construct when used as the name will properly register its lowercase name

in the function registry so that the name continues to be available via the

``func.`` registry.

.. seealso::

:class:`.GenericFunction`

.. change::

:tags: bug, engine

:tickets: 5048

Fixed issue where the collection of value processors on a

:class:`.Compiled` object would be mutated when "expanding IN" parameters

were used with a datatype that has bind value processors; in particular,

this would mean that when using statement caching and/or baked queries, the

same compiled._bind_processors collection would be mutated concurrently.

Since these processors are the same function for a given bind parameter

namespace every time, there was no actual negative effect of this issue,

however, the execution of a :class:`.Compiled` object should never be

causing any changes in its state, especially given that they are intended

to be thread-safe and reusable once fully constructed.

.. change::

:tags: tests, postgresql

:tickets: 5057

Improved detection of two phase transactions requirement for the PostgreSQL

database by testing that max_prepared_transactions is set to a value

greater than 0. Pull request courtesy Federico Caselli.

.. change::

:tags: bug, orm, engine

:tickets: 5056, 5050, 5071

Added test support and repaired a wide variety of unnecessary reference

cycles created for short-lived objects, mostly in the area of ORM queries.

Thanks much to Carson Ip for the help on this.

.. change::

:tags: orm, bug

:tickets: 5107

Fixed regression in loader options introduced in 1.3.0b3 via :ticket:`4468`

where the ability to create a loader option using

:meth:`.PropComparator.of_type` targeting an aliased entity that is an

inheriting subclass of the entity which the preceding relationship refers

to would fail to produce a matching path. See also :ticket:`5082` fixed

in this same release which involves a similar kind of issue.

.. change::

:tags: bug, tests

:tickets: 4946

Fixed a few test failures which would occur on Windows due to SQLite file

locking issues, as well as some timing issues in connection pool related

tests; pull request courtesy Federico Caselli.

.. change::

:tags: orm, bug

:tickets: 5082

Fixed regression in joined eager loading introduced in 1.3.0b3 via

:ticket:`4468` where the ability to create a joined option across a

:func:`.with_polymorphic` into a polymorphic subclass using

:meth:`.RelationshipProperty.of_type` and then further along regular mapped

relationships would fail as the polymorphic subclass would not add itself

to the load path in a way that could be located by the loader strategy. A

tweak has been made to resolve this scenario.

.. change::

:tags: performance, orm

Identified a performance issue in the system by which a join is constructed

based on a mapped relationship. The clause adaption system would be used

for the majority of join expressions including in the common case where no

adaptation is needed. The conditions under which this adaptation occur

have been refined so that average non-aliased joins along a simple

relationship without a "secondary" table use about 70% less function calls.

.. change::

:tags: usecase, postgresql

:tickets: 5040

Added support for prefixes to the :class:`.CTE` construct, to allow

support for Postgresql 12 "MATERIALIZED" and "NOT MATERIALIZED" phrases.

Pull request courtesy Marat Sharafutdinov.

.. seealso::

:meth:`.HasCTE.cte`

.. change::

:tags: bug, mssql

:tickets: 5045

Fixed issue where a timezone-aware ``datetime`` value being converted to

string for use as a parameter value of a :class:`.mssql.DATETIMEOFFSET`

column was omitting the fractional seconds.

.. change::

:tags: bug, orm

:tickets: 5068

Repaired a warning in the ORM flush process that was not covered by test

coverage when deleting objects that use the "version_id" feature. This

warning is generally unreachable unless using a dialect that sets the

"supports_sane_rowcount" flag to False, which is not typically the case

however is possible for some MySQL configurations as well as older Firebird

drivers, and likely some third party dialects.

.. change::

:tags: bug, orm

:tickets: 5065

Fixed bug where usage of joined eager loading would not properly wrap the

query inside of a subquery when :meth:`.Query.group_by` were used against

the query. When any kind of result-limiting approach is used, such as

DISTINCT, LIMIT, OFFSET, joined eager loading embeds the row-limited query

inside of a subquery so that the collection results are not impacted. For

some reason, the presence of GROUP BY was never included in this criterion,

even though it has a similar effect as using DISTINCT. Additionally, the

bug would prevent using GROUP BY at all for a joined eager load query for

most database platforms which forbid non-aggregated, non-grouped columns

from being in the query, as the additional columns for the joined eager

load would not be accepted by the database.