distinguished for when it was actually the value ``False``.
The ``__abstract__`` flag needs to acutally evaluate to a True
value at the level being tested.
fixes#3097
when we do a get; we return the None as always but we leave the dict blank
and the loader callable still in place. The case for this implicit get on a pending object is not
super common and there really should be no change in state at all when this
operation proceeds. This change is more dramatic as it reverses
a behavior SQLA has had since the first release.
fixes#3061
fix that is updated more comprehensively in 1.0 via 🎫`3061`.
The fix in 🎫`3060` unfortunately produces a new issue whereby
an eager load of a many-to-one attribute can produce an event
that is interpreted into an attribute change.
mapper is implicitly combining one of its column-based attributes
with that of the parent, where those columns normally don't necessarily
share the same value. This is an extension of an existing check that
was added via 🎫`1892`; however this new check emits only a
warning, instead of an exception, to allow for applications that may
be relying upon the existing behavior.
fixes#3042
when that :class:`.Column` is referred to in an explicit
:class:`.PrimaryKeyConstraint` for that table. This behavior now
matches that of when the :class:`.Column` itself has the
:paramref:`.Column.primary_key` flag set to ``True``, which is
intended to be an exactly equivalent case.
fixes#3023
While "oid" is generally a private type within PG that is not exposed
in modern versions, there are some PG use cases such as large object
support where these types might be exposed, as well as within some
user-reported schema reflection use cases.
fixes#3002
on an index needed to have the same quoting for quoted names in
order to be recognized. The fix makes the quotes optional but
also provides the old behavior for backwards compatibility with those
using the workaround.
fixes#3085
columns are always added to the list of columns to be "undeferred";
otherwise, the ORM can't load the row's identity. Apparently,
one can defer the mapped primary keys and the ORM will fail, that
hasn't been changed. But as load_only is essentially saying
"defer all but X", it's more critical that PK cols not be part of this
deferral. fixes#3080
- Fixed bug which would occur if a DBAPI exception
occurs when the engine first connects and does its initial checks,
and the exception is not a disconnect exception, yet the cursor
raises an error when we try to close it. In this case the real
exception would be quashed as we tried to log the cursor close
exception via the connection pool and failed, as we were trying
to access the pool's logger in a way that is inappropriate
in this very specific scenario. fixes#3063
mixin or abstract class when accessed, so that modifications made
to this dictionary by declarative itself won't conflict with that
of other mappings. The dictionary is modified regarding the
``version_id_col`` and ``polymorphic_on`` arguments, replacing the
column within with the one that is officially mapped to the local
class/table. fixes#3062
if an exception is a "disconnect" error; ideally, this should remove
the need for any other inspection of the exception message to detect
disconnect, however we will leave those existing messages in place
as a fallback. This should be able to handle newer cases like
"SSL EOF" conditions. Pull request courtesy Dirk Mueller.
fixes#3021
of work such that loading for related many-to-one objects is slightly
more aggressive, in the case of a graph of self-referential objects
that are to be deleted; the load of related objects is to help
determine the correct order for deletion if passive_deletes is
not set.
- revert the changes to test_delete_unloaded_m2o, these deletes do in fact
need to occur in the order of the two child objects first.
that might take one of multiple directions; apply this to test_delete_unloaded_m2o
which is now illustrating multiple paths due to #3060/#3061, though still doing the
right thing.
implicitly initialized to None via first access; this action,
which has always resulted in a population of the attribute,
now emits an attribute event just like any other attribute set
operation and generates the same kind of history as one. Additionally,
many mapper internal operations will no longer implicitly generate
these "None" values when various never-set attributes are checked.
These are subtle behavioral fixes to attribute mechanics which provide
a better solution to the problem of 🎫`3060`, which also
involves recognition of attributes explicitly set to ``None``
vs. attributes that were never set.
fixes#3061
Mike Bayer