- add support for correlations to propagate all the way in; because
correlations require context now, need to make sure a select enclosure
of any level takes effect any number of levels deep.
- fix what we said correlate_except() was supposed to do when we first
released #2668 - "the FROM clause is left intact if the correlated SELECT
is not used in the context of an enclosing SELECT..." - it was not
considering the "existing_froms" collection at all, and prohibited
additional FROMs from being placed in an any() or has().
- add test for multilevel any()
- lots of docs, including glossary entries as we really need to define
"WHERE clause", "columns clause" etc. so that we can explain correlation better
- based on the insight that a SELECT can correlate anything that ultimately
came from an enclosing SELECT that links to this one via WHERE/columns/HAVING/ORDER BY,
have the compiler keep track of the FROM lists that correspond in this way,
link it to the asfrom flag, so that we send to _get_display_froms() the exact
list of candidate FROMs to correlate. no longer need any asfrom logic in the
Select() itself
- preserve 0.8.1's behavior for correlation when no correlate options are given, not
to mention 0.7 and prior's behavior of not propagating implicit correlation more than one level..
this is to reduce surprises/hard-to-debug situations when a user isn't trying
to correlate anything.
- remove most use of "whereclause" and "from_obj", not done yet,
part of [ticket:2679]
- add links to method chained versions for all Select.append_XYZ()
calls
- add "method chaining" and "generative" to glossary
- redefine inspect(Class.attrname).parent to be always an inspectable
target; either Mapper or AliasedInsp
- add most major features to 08 migration, document, link
to the "engines and connections" chapter nobody reads, put big green "note:"
boxes with the word "discouraged" in them for "bound metadata", "implicit execution",
"threadlocal strategy"
- epic documentation sweep for new operator system, making ORM links consistent
and complete, full documentation and examples for type/SQL expression feature
- type_coerce() explicitly accepts BindParamClause objects
- change UserDefinedType to coerce the other side to itself by default as this
is much more likely what's desired
- make coerce_compared_type() fully public on all types
- have profiling run the test no matter what so that the test_zoomarks don't fail
when callcounts are missing
classes, produces the _Over() construct which
in turn generates "window functions", i.e.
"<window function> OVER (PARTITION BY <partition by>,
ORDER BY <order by>)".
[ticket:1844]
Mike Bayer