- locate_all_froms() is expensive; added an attribute-level cache for it
- put a huge warning on all select.append_XXX() methods stating that derived collections like locate_all_froms() may become invalid if
already initialized
selectable expressions. On the SQL side this is represented by the
"corresponding_column()" method. This method is used heavily by the ORM
to "adapt" elements of an expression to similar, aliased expressions,
as well as to target result set columns originally bound to a
table or selectable to an aliased, "corresponding" expression. The new
rewrite features completely consistent and accurate behavior.
- the "orig_set" and "distance" elements as well as all associated
fanfare are gone (hooray !)
- columns now have an optional "proxies" list which is a list of all
columns they are a "proxy" for; only CompoundSelect cols proxy more than one column
(just like before). set operations are used to determine lineage.
- CompoundSelects (i.e. unions) only create one public-facing proxy column per
column name. primary key collections come out with just one column per embedded
PK column.
- made the alias used by eager load limited subquery anonymous.
table joined to a limited subquery of itself; the eager loads now
join directly to the subquery which also provides the primary table's
columns to the result set. This eliminates a JOIN from all eager loads
with LIMIT/OFFSET. [ticket:843]
and "correct" version which will copy all elements exactly once, except for those which were
replaced with target elements. It also can match a wider variety of target elements including
joins and selects on identity alone.
- removed ClauseParameters object; compiled.params returns a regular dictionary
now, as well as result.last_inserted_params()/last_updated_params().
- various code trimming, method removals.
based default generators on them; SQL expression executes inline as normal
but will not trigger a "postfetch" condition for the column, for those DB's
who provide it via cursor.lastrowid
in result-set processing; nested selects which contain the same column
names don't affect the result or conflict with result-column metadata.
- query.get() and related functions (like many-to-one lazyloading)
use compile-time-aliased bind parameter names, to prevent
name conflicts with bind parameters that already exist in the
mapped selectable.
sets (i.e. when no TypeEngine/String/Unicode type is even being used;
previously it was detecting DBAPI types and converting regardless).
should fix [ticket:800]
- fixed oracle out_parameters, likely broke in beta6
- fixed oracle _normalize_case for encoded names, gets unicode reflection test to work
- a few extra tests tweaked/unsupported for oracle
dictionary of QueryContext is now passed to SelectionContext inside
of Query.instances(), allowing messages to be passed between the two stages.
- removed the recent "exact match" behavior of Alias objects, they're back to
their usual behavior.
- tightened up the relationship between the Query's generation
of "eager load" aliases, and Query.instances() which actually grabs the
eagerly loaded rows. If the aliases were not specifically generated for
that statement by EagerLoader, the EagerLoader will not take effect
when the rows are fetched. This prevents columns from being grabbed accidentally
as being part of an eager load when they were not meant for such, which can happen
with textual SQL as well as some inheritance situations. It's particularly important
since the "anonymous aliasing" of columns uses simple integer counts now to generate
labels.
to TEXT/CLOB when no length is present now occurs *only* for an exact type
of String or Unicode with no arguments. If you use VARCHAR or NCHAR
(subclasses of String/Unicode) with no length, they will be interpreted
by the dialect as VARCHAR/NCHAR; no "magic" conversion happens there.
This is less surprising behavior and in particular this helps Oracle keep
string-based bind parameters as VARCHARs and not CLOBs [ticket:793].
to the label used in the generated statement. This is so searching for columns in a
result row which match aliases won't accidentally match non-aliased columns.
fixes errors which can arise in eager loading scenarios.
~(x <operator> y) produces NOT (x <op> y), which is better compatible with MySQL.
[ticket:764]. this doesn't apply to "~(x==y)" as it does in 0.3 since ~(x==y)
compiles to "x != y", but still applies to operators like BETWEEN.
"column_keys". the parameters sent to execute() only interact with the
insert/update statement compilation process in terms of the column names
present but not the values for those columns.
produces more consistent execute/executemany behavior, simplifies things a
bit internally.
- inline default execution occurs for *all* non-PK columns
unconditionally - preexecute only for non-executemany PK cols on
PG, Oracle, etc.
- new default docs
- all executemany() style calls put all sequences and SQL defaults inline into a single SQL statement
and don't do any pre-execution
- regular Insert and Update objects can have inline=True, forcing all executions to be inlined.
- no last_inserted_ids(), lastrow_has_defaults() available with inline execution
- calculation of pre/post execute pushed into compiler; DefaultExecutionContext greatly simplified
- fixed postgres reflection of primary key columns with no sequence/default generator, sets autoincrement=False
- fixed postgres executemany() behavior regarding sequences present, not present, passivedefaults, etc.
- all tests pass for sqlite, mysql, postgres; oracle tests pass as well as they did previously including all
insert/update/default functionality
Mike Bayer