Fixed bug where an :func:`.undefer_group` option would not be recognized
if it extended from a relationship that was loading using joined eager
loading.
In particular we need to double check the column both in terms of
the given "adapter" as well as without applying the "adapter"
when searching for the column in the result.
As we now avoid redoing the row processor step we also
improve on callcounts in joined eager loading.
Change-Id: I0f48766f12f7299f4626ff41a00bf1f5bfca5f3b
Fixes: #4048
Fixed regression where the use of a :func:`.undefer_group` option
in conjunction with a lazy loaded relationship option would cause
an attribute error, due to a bug in the SQL cache key generation
added in 1.2 as part of 🎫`3954`.
Change-Id: Icd9a34f0b5aa96d6433a2ab9c8d3eaee0006f609
Fixes: #4049
The attributeimpl for a deferred_expression does not
support a scalar loader, add new configurability so that
the impl can have this flag turned off. Document
that the with_expression() system currently does not
offer any deferred loading.
To eliminate confusion over "deferred", which refers to
lazy loading of column attributes, and "with_expression",
which refers to an attribute that is explicitly at
query time only, rename deferred_expression to query_expression.
Change-Id: I07c4a050ed68c79ccbde9492e9de1630b7470d74
Added a new feature :func:`.orm.with_expression` that allows an ad-hoc
SQL expression to be added to a specific entity in a query at result
time. This is an alternative to the SQL expression being delivered as
a separate element in the result tuple.
Change-Id: Id8c479f7489fb02e09427837c59d1eabb2a6c014
Fixes: #3058
Adds a new variant to the "isnew" state within entity loading
for isnew=False, but the load path is new. This is to address
the use case of an entity appearing in multiple places in
the row in a more generalized way than the fixes in [ticket:3431],
[ticket:3811] in that loading.py will be able to tell the
populator that this row is not "isnew" but is a "new" path
for the entity. For the moment, the new information is only
being applied to the use of "quick" populators so that
simple column loads can take place on top of a deferred loader
from elsewhere in the row.
As part of this change, state.load_path() will now always
be populated with the "path" that was in effect when this state
was originally loaded, which for multi-path loads of the
same entity is still non-deterministic. Ideally there'd be some
kind of "here's all the paths that loaded this state and how"
type of data structure though it's not clear if that could be
done while maintaining performance.
Fixes: #3822
Change-Id: Ib915365353dfcca09e15c24001a8581113b97d5e
This is an old parameter no longer relevant to how SQLAlchemy
works, once the Query object was introduced. By deprecating it
we establish that we aren't supporting non-working use cases
and that we encourage applications to move off of the use of this
parameter.
Fixes: #3394
Change-Id: I25b9a38142a1537bbcb27d3e8b66a8b265140072
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
a much more modest outcome than what we started with. The
work of create_row_processor() for ColumnProperty objects
is essentially done at query setup time combined with some
lookups in _instance_processor().
- to allow this change for deferred columns, deferred columns
no longer search for themselves in the result. If they've been
set up as deferred without any explicit directive to undefer them,
then this is what was asked for. if we don't do this,
then we're stuck with this performance penalty for all deferred
columns which in the vast majority of typical use cases (e.g. loading
large, legacy tables or tables with many/large very seldom
used values) won't be present in the result and won't be accessed at all.
the :func:`.orm.load_only` option to cover all attributes not
explicitly mentioned, now takes into account the superclasses
of a given entity, if that entity is mapped with inheritance mapping,
so that attribute names within the superclasses are also omitted
from the load. Additionally, the polymorphic discriminator column
is unconditionally included in the list, just in the same way that
primary key columns are, so that even with load_only() set up,
polymorphic loading of subtypes continues to function correctly.
fixes#3287
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
- The system of loader options has been entirely rearchitected to build
upon a much more comprehensive base, the :class:`.Load` object. This
base allows any common loader option like :func:`.joinedload`,
:func:`.defer`, etc. to be used in a "chained" style for the purpose
of specifying options down a path, such as ``joinedload("foo").subqueryload("bar")``.
The new system supersedes the usage of dot-separated path names,
multiple attributes within options, and the usage of ``_all()`` options.
- Added a new load option :func:`.orm.load_only`. This allows a series
of column names to be specified as loading "only" those attributes,
deferring the rest.
Mike Bayer