Change-Id: Ib9a69e20420e1fda755f4533c5f90bc08ba11b48
References: #8879
References: #9101
(cherry picked from commit 5e6cb26a017fb72bc3f925194c6f8c1eda968fbe)

this UPDATE refers to the unit of work's need to consider this
additional UPDATE as a dependency and not an actual UPDATE statement.

Change-Id: I2a520af21ebf96b45c431efa898d4e7683a5bc2d
References: #9066
References: #1063
(cherry picked from commit 2ef4b449a7709ecab45e926f0e8d0dd398fd12db)

Change-Id: I14db8e9c69a832b0f5dae8036db3c0a70bb49edd

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
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.

Fixes: #8881
Change-Id: Ie939b1470cb2e824717384be65f4cd8edd619942
(cherry picked from commit 474326e87038f997fb9423c56379b8ba19a5e43b)

Fixed bug where :meth:`_orm.Session.merge` would fail to preserve the
current loaded contents of relationship attributes that were indicated with
the :paramref:`_orm.relationship.viewonly` parameter, thus defeating
strategies that use :meth:`_orm.Session.merge` to pull fully loaded objects
from caches and other similar techniques. In a related change, fixed issue
where an object that contains a loaded relationship that was nonetheless
configured as ``lazy='raise'`` on the mapping would fail when passed to
:meth:`_orm.Session.merge`; checks for "raise" are now suspended within
the merge process assuming the :paramref:`_orm.Session.merge.load`
parameter remains at its default of ``True``.

Overall, this is a behavioral adjustment to a change introduced in the 1.4
series as of :ticket:`4994`, which took "merge" out of the set of cascades
applied by default to "viewonly" relationships. As "viewonly" relationships
aren't persisted under any circumstances, allowing their contents to
transfer during "merge" does not impact the persistence behavior of the
target object. This allows :meth:`_orm.Session.merge` to correctly suit one
of its use cases, that of adding objects to a :class:`.Session` that were
loaded elsewhere, often for the purposes of restoring from a cache.

Fixes: #8862
Change-Id: I8731c7810460e6a71f8bf5e8ded59142b9b02956
(cherry picked from commit 1e009bf086a42134190030f07068bc463e9a9794)

* Explicitly state what happens if `order_by` is called more than once.

The existing docs cover how to clear existing `order_by` clauses but don't actually describe the behavior of calling `order_by` multiple times with different clauses.

* Also update Select.order_by.

(cherry picked from commit 9237bf15e612ba82555444751bd69dc2a831e7f4)

Improved "dictionary mode" for :meth:`_orm.Session.get` so that synonym
names which refer to primary key attribute names may be indicated in the
named dictionary.

Fixes: #8753
Change-Id: I56112564a5c23b51b26e01c64087cbf4399cd951
(cherry picked from commit 7b6259c0f3ae411976f8febfe41f2c5fc3490b13)

Fixed issue where the underlying DBAPI cursor would not be closed when
using :class:`_orm.Query` and direct iteration, if a user-defined exception
case were raised within the iteration process, interrupting the iterator
which otherwise is not possible to re-use in this context. When using
:meth:`_orm.Query.yield_per` to create server-side cursors, this would lead
to the usual MySQL-related issues with server side cursors out of sync.

To resolve, a catch for ``GeneratorExit`` is applied within the default
iterator, which applies only in those cases where the interpreter is
calling ``.close()`` on the iterator in any case.

A similar scenario can occur when using :term:`2.x` executions with direct
use of :class:`.Result`, in that case the end-user code has access to the
:class:`.Result` itself and should call :meth:`.Result.close` directly.
Version 2.0 will feature context-manager calling patterns to address this
use case.  However within the 1.4 scope, ensured that ``.close()`` methods
are available on all :class:`.Result` implementations including
:class:`.ScalarResult`, :class:`.MappingResult`.

Fixes: #8710
Change-Id: I3166328bfd3900957eb33cbf1061d0495c9df670

since these methods have been improved for 2.0, the general
idea is not going away, so remove the warnings indicating
that these features are being removed.

Change-Id: I2c436c2e7f9aeacc9e71c82af4016190314f04ca