by the versioning example is deprecated;
now use mapper.get_property_by_column() which
will remain the public method for this.
- turned TODO in the history example into an assertion
with a descriptive reason
"basic relationship" examples, cleaned up the examples and added
some more explicitness. Also renamed "treenodes" to "nodes" and
added self-referential declarative example.
- Added info/examples on how to join tables directly when querying with
joined table inheritance.
- Starting to talk about hybrids in the main mapper docs some more.
introducoed the idea that synonyms are on their way out.
- SQL expressions as mapped attributes also gets better verbiage,
alternative approaches to them, including hybrids.
- modernized the hybrid example.
- object_session() as a standalone function wasn't documented ?!
such that the Session, cache manager,
declarative_base are part of environment, and
custom cache code is portable and now within
"caching_query.py". This allows the example to
be easier to "drop in" to existing projects.
relationship(), to eliminate confusion over the relational
algebra term. relation() however will remain available
in equal capacity for the foreseeable future. [ticket:1740]
RelationCache option for lazyload caching. This object
does a lookup among any number of potential attributes
more efficiently by grouping several into a common structure.
Both FromCache and RelationCache are simpler individually.
- added READMEs to all examples in each __init__.py and added to sphinx documentation
- added versioning example
- removed vertical/vertical.py, the dictlikes are more straightforward
more information for custom mapper opts to see what's going on. add a new _reduce_path()
function to apply to the path as stored in dictionaries, adds a slight cost overhead.
given instance is the same instance which is already present.
- merge() now also merges the "options" associated with a given
state, i.e. those passed through query.options() which follow
along with an instance, such as options to eagerly- or
lazyily- load various attributes. This is essential for
the construction of highly integrated caching schemes. This
is a subtle behavioral change vs. 0.5.
- A bug was fixed regarding the serialization of the "loader
path" present on an instance's state, which is also necessary
when combining the usage of merge() with serialized state
and associated options that should be preserved.
- The "query_cache" examples have been removed, and are replaced
with a fully comprehensive approach that combines the usage of
Beaker with SQLAlchemy. New query options are used to indicate
the caching characteristics of a particular Query, which
can also be invoked deep within an object graph when lazily
loading related objects. See /examples/beaker_caching/README.
types to more intelligently determine float() vs. Decimal(),
[ticket:1567]
- since result processing is a hot issue of late, the DBAPI type
returned from cursor.description is certainly useful in cases like
these to determine an efficient result processor. There's likely
other result processors that can make use of it. But, backwards
incompat change to result_processor(). Happy major version number..
Explicit imports make it easier for users to understand the examples.
Additionally a lot of the examples were fixed to work with the changes in the
0.5.x code base. One small correction to the Case expression. Thanks a bunch
to Adam Lowry! Fixes#717.
class. It can be subclassed to provide user-defined
SQL functions in an imperative style, including
with pre-established behaviors. The postgis.py
example illustrates one usage of this.
column_property(), relation() etc. can define
new comparison methods on the Comparator, which will
become available via __getattr__() on the
InstrumentedAttribute. In the case of synonym()
or comparable_property(), attributes are resolved first
on the user-defined descriptor, then on the user-defined
comparator.
accurately adapt the expressions generated, which helps
particularly with self-referential comparisons. [ticket:1171]
- Fixed bug involving primaryjoin/secondaryjoin conditions
constructed from class-bound attributes (as often occurs
when using declarative), which later would be inappropriately
aliased by Query, particularly with the various EXISTS
based comparators.
Mike Bayer