specific to mapper inheritance
- tweak Proxy property to give the proxied descriptor a chance to raise
an exception
- have Concrete prop raise on all access, not just trying to use it
in a query.  This might be a little problematic backwards compatible-wise, however
- adjust mapper and relationship to more correctly allow for concreteinheritedprop
to be overridden, in the case of backrefs etc., some cases were still raising
due to how props are set up
- work assert_raises/assert_raises_message to be expressed via a context manager
that can be used directly

be used to manufacture objects that behave as though they were loaded
from a session, then detached.   Attributes that aren't present
are marked as expired, and the object can be added to a Session
where it will act like a persistent one. fix #3017

- alter this in the unit tests as well as these queries were just copied from the tests
- remove the included_parts.join(parts) from the core CTE doc (also just copied from the
test, where we want to make sure joins don't get screwed up with the CTE) as it doesn't
contribute to the query itself
fixes #3014

the new rules for "where" and "having" woudn't take effect for the
"whereclause" and "having" kw arguments of the :func:`.select` construct,
which is also what :class:`.Query` uses so wasn't working in the
ORM either. fixes #3013 re: #2804

to True, indicates that a series of DELETE statements should confirm
that the cursor rowcount matches the number of primary keys that should
have matched;  this behavior had been taken off in most cases
(except when version_id is used) to support the unusual edge case of
self-referential ON DELETE CASCADE; to accomodate this, the message
is now just a warning, not an exception, and the flag can be used
to indicate a mapping that expects self-refererntial cascaded
deletes of this nature.  See also :ticket:`2403` for background on the
original change. re: #2403 fix #3007

where one is to be deleted from ON DELETE CASCADE succeeds; the check here makes that fail.
We will need to add an option to enable/disable this check per mapping, will likely
do this in next version

it for DELETE would fail to target the correct row for DELETE.
Then to compound matters, basic "number of rows matched" checks were
not being performed.  Both issues are fixed, however note that the
"rows matched" check requires so-called "sane multi-row count"
functionality; the DBAPI's executemany() method must count up the
rows matched by individual statements and SQLAlchemy's dialect must
mark this feature as supported, currently applies to some mysql dialects,
psycopg2, sqlite only. fixes #3006
- Enabled "sane multi-row count" checking for the psycopg2 DBAPI, as
this seems to be supported as of psycopg2 2.0.9.

could inappropriately pull in the parent table, and also return results
inconsistent based on what's in the parent table, when the primaryjoin
includes some kind of discriminator against the parent table, such
as ``and_(parent.id == child.parent_id, parent.deleted == False)``.
While this primaryjoin doesn't make that much sense for a one-to-many,
it is slightly more common when applied to the many-to-one side, and
the one-to-many comes as a result of a backref.
Loading rows from ``child`` in this case would keep ``parent.deleted == False``
as is within the query, thereby yanking it into the FROM clause
and doing a cartesian product.  The new behavior will now substitute
the value of the local "parent.deleted" for that parameter as is
appropriate.   Though typically, a real-world app probably wants to use a
different primaryjoin for the o2m side in any case.
fixes #2948