SQLAlchemy version 0.7.2 is now available.
A lot has been going on leading up to this release, and there was actually a
bunch more I've wanted to do; but as we went about six weeks since the last
release we've accumulated at least twenty five bug fixes, and it's time for
them to go out.Work continues towards the next release.
This release features a relatively big change to the mechanics of joined and
subquery eager loading, which is that when invoked from a Query (as opposed to
from a lazy load), the eager loader will traverse the graph of objects fully
regardless of collections and attributes that are already loaded, populating
any expired or not-yet-loaded attributes all the way down the hierarchy.
Previously it tried to save time by not descending into already loaded
subtrees. This is to better support the use case of using eager loading in
order to fully populate a tree, such that it can be detached and sent to a
cache in a fully loaded state. It is also behaviorally closer to the spirit of
"I asked for X, I should get X", i.e. if you say subqueryload(), you'll get
your subquery no matter what.
Other than that there were a *lot* of ORM fixes, most of which have been also
applied to the 0.6 branch and will be in 0.6.9. Also some additional 0.6->0.7
regressions fixed, and some fixes to the new "Mutable" extension including one
which was kind of a show stopper.
Download SQLAlchemy 0.7.2 at:
http://www.sqlalchemy.org/download.html
Changelog follows.
0.7.2
=
- orm
- Feature enhancement: joined and subquery
loading will now traverse already-present related
objects and collections in search of unpopulated
attributes throughout the scope of the eager load
being defined, so that the eager loading that is
specified via mappings or query options
unconditionally takes place for the full depth,
populating whatever is not already populated.
Previously, this traversal would stop if a related
object or collection were already present leading
to inconsistent behavior (though would save on
loads/cycles for an already-loaded graph). For a
subqueryload, this means that the additional
SELECT statements emitted by subqueryload will
invoke unconditionally, no matter how much of the
existing graph is already present (hence the
controversy). The previous behavior of "stopping"
is still in effect when a query is the result of
an attribute-initiated lazyload, as otherwise an
"N+1" style of collection iteration can become
needlessly expensive when the same related object
is encountered repeatedly. There's also an
as-yet-not-public generative Query method
_with_invoke_all_eagers()
which selects old/new behavior [ticket:2213]
- A rework of "replacement traversal" within
the ORM as it alters selectables to be against
aliases of things (i.e. clause adaption) includes
a fix for multiply-nested any()/has() constructs
against a joined table structure. [ticket:2195]
- Fixed bug where query.join() + aliased=True
from a joined-inh structure to itself on
relationship() with join condition on the child
table would convert the lead entity into the
joined one inappropriately. [ticket:2234]
Also in 0.6.9.
- Fixed regression from 0.6 where Session.add()
against an object which contained None in a
collection would raise an internal exception.
Reverted this to 0.6's behavior which is to
accept the None but obviously nothing is
persisted. Ideally, collections with None
present or on append() should at least emit a
warning, which is being considered for 0.8.
[ticket:2205]
- Load of a deferred() attribute on an object
where row can't be located raises
ObjectDeletedError instead of failing later
on; improved the message in ObjectDeletedError
to include other conditions besides a simple
"delete". [ticket:2191]
- Fixed regression from 0.6 where a get history
operation on some relationship() based attributes
would fail when a lazyload would emit; this could
trigger within a flush() under certain conditions.
[ticket:2224] Thanks to the user who submitted
the great test for this.
- Fixed bug apparent only in Python 3 whereby
sorting of persistent + pending objects during
flush would produce an illegal comparison,
if the persistent object primary key
is not a single integer. [ticket:2228]
Also in 0.6.9
- Fixed bug whereby the source clause
used by query.join() would be inconsistent
if against a column expression that combined
multiple entities together. [ticket:2197]
Also in 0.6.9
- Fixed bug whereby if a mapped class
redefined __hash__() or __eq__() to something
non-standard, which is a supported use case
as SQLA should never consult these,
the methods would be consulted if the class
was part of a "composite" (i.e. non-
