in the select statement by something other than the eager loader
itself, to fix possibility of dupe columns as illustrated in
[ticket:495]. however, this means you have to be more careful with
the columns placed in the "order by" of Query.select(), that you have
explicitly named them in your criterion (i.e. you cant rely on the
eager loader adding them in for you)
- query._join_to (which powers join, join_via, etc) properly takes
secondary table into account when constructing joins
SchemaItem so that the traversal of items is controlled by the
ClauseVisitor itself, using the method visitor.traverse(item).
accept_visitor() methods can still be called directly but will
not do any traversal of child items. ClauseElement/SchemaItem now
have a configurable get_children() method to return the collection
of child elements for each parent object. This allows the full
traversal of items to be clear and unambiguous (as well as loggable),
with an easy method of limiting a traversal (just pass flags which
are picked up by appropriate get_children() methods). [ticket:501]
- accept_schema_visitor() methods removed, replaced with
get_children(schema_visitor=True)
- various docstring/changelog cleanup/reformatting
- got binary working for any size input ! cx_oracle works fine,
it was my fault as BINARY was being passed and not BLOB for
setinputsizes (also unit tests werent even setting input sizes).
- auto_setinputsizes defaults to True for Oracle, fixed cases where
it improperly propigated bad types.
will add the given mapper/class or ColumnElement to the query at compile
time, and apply them to the instances method. the user is responsible
for constructing reasonable join conditions (otherwise you can get
full cartesian products). result set is the list of tuples, non-uniqued.
- fixed multi-mapper instances() to pad out shorter results with None so
zip() gets everything
into a new set of methods available off of Query. These methods
all provide "generative" behavior, whereby the Query is copied
and a new one returned with additional criterion added.
The new methods include:
filter() - applies select criterion to the query
filter_by() - applies "by"-style criterion to the query
avg() - return the avg() function on the given column
join() - join to a property (or across a list of properties)
outerjoin() - like join() but uses LEFT OUTER JOIN
limit()/offset() - apply LIMIT/OFFSET
range-based access which applies limit/offset:
session.query(Foo)[3:5]
distinct() - apply DISTINCT
list() - evaluate the criterion and return results
no incompatible changes have been made to Query's API and no methods
have been deprecated. Existing methods like select(), select_by(),
get(), get_by() all execute the query at once and return results
like they always did. join_to()/join_via() are still there although
the generative join()/outerjoin() methods are easier to use.
- the return value for multiple mappers used with instances() now returns
a cartesian product of the requested list of mappers, represented
as a list of tuples. this corresponds to the documented behavior.
So that instances match up properly, the "uniquing" is disabled when
this feature is used.
- strings and columns can also be sent to the *args of instances() where
those exact result columns will be part of the result tuples.
- query() method is added by assignmapper. this helps with
navigating to all the new generative methods on Query.
requires that the target column be present in a sub-element of the
target selectable.
- embedded logic above more appropriate for ClauseAdapter functionality
since its trying to "pull up" clauses that represent columns within
a larger union up to the level of the union itself.
- the "direction" test against the "foreign_keys" collection apparently
works for an exact "column 'x' is present in the collection", no proxy
relationships needed. fixes the case of relating a selectable/alias
to one of its underlying tables, probably fixes other scenarios
of B's, but you put a C in the collection" error condition -
**even if C is a subclass of B**, unless B's mapper loads polymorphically.
Otherwise, the collection will later load a "B" which should be a "C"
(since its not polymorphic) which breaks in bi-directional relationships
(i.e. C has its A, but A's backref will lazyload it as a different
instance of type "B") [ticket:500]
distinct bindparam()s with the same name in a single statement,
and the key will be shared. proper positional/named args translate
at compile time. for the old behavior of "aliasing" bind parameters
with conflicting names, specify "unique=True" - this option is
still used internally for all the auto-genererated (value-based)
bind parameters.
'duplicate' columns from the resulting column clause that are known to be
equivalent based on the join condition. this is of great usage when
constructing subqueries of joins which Postgres complains about if
duplicate column names are present.
- added support to polymorphic stuff for more than one "equivalent column",
when trying to target columns in the polymorphic union; this applies
to multi-leveled inheritance
- put above-two concepts together to get the abc_inheritance tests to work
with postgres
column elements, since we can make no assumptions about the text. to
create labels for literal columns, you can say "somecol AS somelabel",
or use literal_column("somecol").label("somelabel")
- quoting wont occur for literal columns when they are "proxied" into the
column collection for their selectable (is_literal flag is propigated)
worked anyway), but also query.selectfirst(), query.selectone() which
will be used as is (i.e. no query is compiled). works similarly to
sending the results to instances().
you must now use the "collection_class" option. the old way was
beginning to produce conflicts when people used assign_mapper(), which
now patches an "options" method, in conjunction with a relationship
named "options". (relationships take precedence over monkeypatched
assign_mapper methods).
take place without knowning so much about properties
- mapper options like eagerload(), lazyload(), deferred(), will work for "synonym()" relationships [ticket:485]
except for DBLINK which I cannot get to work on my oracle-xe database.
- probable (also untested) fix for [ticket:363], better error message if we get None back for
remote table information (which is due to rights)
Rick Morrison