the warning here to all safe_reraise() cases in Python 2.
- Revisiting :ticket:`2696`, first released in 1.0.10, which attempts to
work around Python 2's lack of exception context reporting by emitting
a warning for an exception that was interrupted by a second exception
when attempting to roll back the already-failed transaction; this
issue continues to occur for MySQL backends in conjunction with a
savepoint that gets unexpectedly lost, which then causes a
"no such savepoint" error when the rollback is attempted, obscuring
what the original condition was.

The approach has been generalized to the Core "safe
reraise" function which takes place across the ORM and Core in any
place that a transaction is being rolled back in response to an error
which occurred trying to commit, including the context managers
provided by :class:`.Session` and :class:`.Connection`, and taking
place for operations such as a failure on "RELEASE SAVEPOINT".
Previously, the fix was only in place for a specific path within
the ORM flush/commit process; it now takes place for all transational
context managers as well.
fixes #2696

available mapper options.   This allows a DELETE to proceed
for a joined-table inheritance mapping against the base table only,
while allowing for ON DELETE CASCADE to handle deleting the row
from the subclass tables.
fixes #2349

is random; therefore it may be called against the subclass mapper first, so
need to check .concrete on both sides, references #3630

a base class and a concrete-inherited subclass would raise an error
if those relationships were set up using "backref", while setting up the
identical configuration using relationship() instead with the conflicting
names would succeed, as is allowed in the case of a concrete mapping.
fixes #3630

the :class:`.Engine` to which the :class:`.Session` is bound, when
generating the string form of the SQL, so that the actual SQL
that would be emitted to the database is shown, if possible.  Previously,
only the engine associated with the :class:`.MetaData` to which the
mappings are associated would be used, if present.  If
no bind can be located either on the :class:`.Session` or on
the :class:`.MetaData` to which the mappings are associated, then
the "default" dialect is used to render the SQL, as was the case
previously.  fixes #3081

intelligible, given the fixes for ref #3623.  unfortunately the system
is still quite weird even though it was rewritten to be... less weird

system failed to accommodate for multiple :func:`.undefer_group`
loader options in a single query.   Multiple :func:`.undefer_group`
options will now be taken into account even against the same
entity. fixes #3623

updated docstrings for orm.scoping