Also clarifies a behavior of None/False for the selectable
parameter to with_polymorphic()

Fixes: #7262
Change-Id: I58c4004e0af227d3995e9ae2461470440f97f252

- Passing bind arguments to Session.execute
- This Session located a target engine via bound metadata

Change-Id: I916c8c4cff344ee5652fceac4dfd241dd8160f7b

There are still some SQLite / MySQL specific occurrences
of "master" but this is most of it.

Change-Id: I0144c992e2f0207777e20e058b63a11c031986b9

a few changes for py2k:

* map_imperatively() includes the check that a class
  is being sent, this was only working for mapper() before

* the test suite didn't place the py2k "autouse" workaround
  in the correct order, seemingly, tried to adjust the
  per-test ordering setup in pytestplugin.py

Change-Id: I4cc39630724e810953cfda7b2afdadc8b948e3c2

* sqlalchemy.ext.declarative names
* declarative_base(bind)

Change-Id: I0ca26894b224458b58e46504c5ff7b5d3031a829

An extra layer of warning messages has been added to the functionality
of :meth:`_orm.Query.join` and the ORM version of
:meth:`_sql.Select.join`, where a few places where "automatic aliasing"
continues to occur will now be called out as a pattern to avoid, mostly
specific to the area of joined table inheritance where classes that share
common base tables are being joined together without using explicit aliases.
One case emits a legacy warning for a pattern that's not recommended,
the other case is fully deprecated.

The automatic aliasing within ORM join() which occurs for overlapping
mapped tables does not work consistently with all APIs such as
``contains_eager()``, and rather than continue to try to make these use
cases work everywhere, replacing with a more user-explicit pattern
is clearer, less prone to bugs and simplifies SQLAlchemy's internals
further.

The warnings include links to the errors.rst page where each pattern is
demonstrated along with the recommended pattern to fix.

* Improved the exception message generated when configuring a mapping with
  joined table inheritance where the two tables either have no foreign key
  relationships set up, or where they have multiple foreign key relationships
  set up. The message is now ORM specific and includes context that the
  :paramref:`_orm.Mapper.inherit_condition` parameter may be needed
  particularly for the ambiguous foreign keys case.

* Add explicit support in the _expect_warnings() assertion for nested
  _expect_warnings calls

* generalize the NoCache fixture, which we also need to catch warnings
  during compilation consistently

* generalize the __str__() method for the HasCode mixin so all warnings
  and errors include the code link in their string

Fixes: #6974
Change-Id: I84ed79ba2112c39eaab7973b6d6f46de7fa80842

Change-Id: I488c9557eda390e4a88319affd4c8813ee274f80

Fixed regression where recent changes to support Python dataclasses had the
inadvertent effect that an ORM mapped class could not successfully override
the ``__new__()`` method.

In this case the "__new__" method comes out as staticmethod in
cls.__dict__ vs. a function in the metaclass dict_, so comparing
using identity fails.   I was hoping not to have too much
"dataclass" hardcoded, the logic here if it were generalized
to other attribute declaration systems there
would still have a flag that indicates an attribute is part of
the "special declaration system".

Fixes: #6331
Change-Id: Ia28a44fb57c668fa2fc5cd1ff38fd511f2c747e6

Applied a series of refactorings and fixes to accommodate for Mypy
"incremental" mode across multiple files, which previously was not taken
into account. In this mode the Mypy plugin has to accommodate Python
datatypes expressed in other files coming in with less information than
they have on a direct run.

Additionally, a new decorator :func:`_orm.declarative_mixin` is added,
which is necessary for the Mypy plugin to be able to definifitely identify
a Declarative mixin class that is otherwise not used inside a particular
Python file.

discussion:

With incremental / deserialized mypy runs, it appears
that when we look at a base class that comes from another file,
cls.info is set to a special undefined node
that matches CLASSDEF_NO_INFO, and we otherwise can't
touch it without crashing.  Additionally, sometimes cls.defs.body
is present but empty.

However, it appears that both of these cases can be sidestepped,
first by doing a lookup() for the type name where we
get a SymbolTableNode that then has the TypeInfo we wanted
when we tried touching cls.info, and then however we got the
TypeInfo, if cls.defs.body is empty we can just look in the
names to get at the symbols for that class; we just can't
access AssignmentStmts, but that's fine because we just
need the information for classes we aren't actually type checking.

This work also revealed there's no easy way to detect a mixin
class so we just create a new decorator to mark that.  will make
code look better in any case.

Fixes: #6147
Change-Id: Ia8fac8acfeec931d8f280491cffc5c6cb4a1204e

Fixed regression where the ``.metadata`` attribute on a per class level
would not be honored, breaking the use case of per-class-hierarchy
:class:`.schema.MetaData` for abstract declarative classes and mixins.

Fixes: #6128
Change-Id: I5c15436b5c5171105dc1a0192fa744daf79a344d