loading available, the new names for eagerload() and
eagerload_all() are joinedload() and joinedload_all(). The
old names will remain as synonyms for the foreseeable future.
- The "lazy" flag on the relationship() function now accepts
a string argument for all kinds of loading: "select", "joined",
"subquery", "noload" and "dynamic", where the default is now
"select". The old values of True/
False/None still retain their usual meanings and will remain
as synonyms for the foreseeable future.
- Added documentation to tutorial,mapper doc, api docs
for subqueryload, subqueryload_all, and other options.
relationship(), to eliminate confusion over the relational
algebra term. relation() however will remain available
in equal capacity for the foreseeable future. [ticket:1740]
- declarative now accepts mixin classes directly, as a means
to provide common functional and column-based elements on
all subclasses, as well as a means to propagate a fixed
set of __table_args__ or __mapper_args__ to subclasses.
For custom combinations of __table_args__/__mapper_args__ from
an inherited mixin to local, descriptors can now be used.
New details are all up in the Declarative documentation.
Thanks to Chris Withers for putting up with my strife
on this. [ticket:1707]
- the __mapper_args__ dict is copied when propagating to a subclass,
and is taken straight off the class __dict__ to avoid any
propagation from the parent. mapper inheritance already
propagates the things you want from the parent mapper.
[ticket:1393]
as the source of class information; _as_declarative exclusively
uses the dict_ passed to it as the source of class information
(which when using DeclarativeMeta is cls.__dict__). This should
in theory make it easier for custom metaclasses to modify
the state passed into _as_declarative.
association_proxy is now (lazy_collection, creator,
value_attr, association_proxy), adding a fourth argument
that is the parent AssociationProxy argument. Allows
serializability and subclassing of the built in collections.
[ticket:1259]
- removed "key" accessor of Function, Grouping - this doesn't seem to be used for anything
- various formatting
- documented the four "Element" classes in the compiler extension as per [ticket:1590]
- removed doctest stuff
- redid session docs for sqlsoup
- sqlsoup stays within the transaction of a Session now, is explcitly autocommit=False by default and includes commit()/rollback() methods
- sqlsoup db.<sometable>.update() and delete() now call
query(cls).update() and delete(), respectively.
- sqlsoup now has execute() and connection(), which call upon
the Session methods of those names, ensuring that the bind is
in terms of the SqlSoup object's bind.
superclass after the class has been constructed
(i.e. via class-level attribute assignment), and
the column will be propagated down to
subclasses. [ticket:1570] This is the reverse
situation as that of [ticket:1523], fixed in 0.5.6.
the class has been constructed (i.e. via class-level
attribute assignment). The column is added to the underlying
Table as always, but now the mapper will rebuild its
"join" to include the new column, instead of raising
an error about "no such column, use column_property()
instead". [ticket:1523]
- added an additional test in test_mappers for "added nonexistent column",
even though this test is already in test_query its more appropriate within
"mapper configuration" tests.
- many-to-one relation to a joined-table subclass now uses get()
for a simple load (known as the "use_get" condition),
i.e. Related->Sub(Base), without the need
to redefine the primaryjoin condition in terms of the base
table. [ticket:1186]
- specifying a foreign key with a declarative column,
i.e. ForeignKey(MyRelatedClass.id) doesn't break the "use_get"
condition from taking place [ticket:1492]
Call session.add() if you'd like a free-standing object to be
part of your session. Otherwise, a DIY version of
Session.mapper is now documented at
http://www.sqlalchemy.org/trac/wiki/UsageRecipes/SessionAwareMapper
The method will remain deprecated throughout 0.6.
M test/ext/test_declarative.py
M test/orm/test_scoping.py
M lib/sqlalchemy/orm/scoping.py
M CHANGES
is a standardized interface which allows the creation of custom
ClauseElement subclasses and compilers. In particular it's
handy as an alternative to text() when you'd like to
build a construct that has database-specific compilations.
See the extension docs for details.
Mike Bayer