could be lost if the statement were used as a subquery
inside of another statement, as well as other similar
situations. Among other things, would cause
typing information to be lost when the Oracle/mssql dialects
would apply limit/offset wrappings. [ticket:2603]
used when producing a "proxy" of the column against
a selectable. This probably didn't occur in 0.7
since 0.7 doesn't respect the ".key" in a wider
range of scenarios. [ticket:2597]
to help with generative building. Also slight adjustment
regarding how SS "correlates" columns; the new methodology
no longer applies meaning to the underlying
Table column being selected. This improves
some fairly esoteric situations, and the logic
that was there didn't seem to have any purpose.
- [feature] Some support for auto-rendering of a
relationship join condition based on the mapped
attribute, with usage of core SQL constructs.
E.g. select([SomeClass]).where(SomeClass.somerelationship)
would render SELECT from "someclass" and use the
primaryjoin of "somerelationship" as the WHERE
clause. This changes the previous meaning
of "SomeClass.somerelationship" when used in a
core SQL context; previously, it would "resolve"
to the parent selectable, which wasn't generally
useful. Related to [ticket:2245].
become an externally usable package but still remains within the main sqlalchemy parent package.
in this system, we use kind of an ugly hack to get the noseplugin imported outside of the
"sqlalchemy" package, while still making it available within sqlalchemy for usage by
third party libraries.
declared on a single-table inheritance subclass
up to the parent class' table, when the parent
class is itself mapped to a join() or select()
statement, directly or via joined inheritane,
and not just a Table. [ticket:2549]
to select() construct, replaces columns inline
using the util.reduce_columns utility function
to remove equivalent columns. reduce_columns()
also adds "with_only_synonyms" to limit the
reduction just to those columns which have the same
name. The deprecated fold_equivalents() feature is
removed [ticket:1729].
- [feature] Added with_labels and
reduce_columns keyword arguments to
Query.subquery(), to provide two alternate
strategies for producing queries with uniquely-
named columns. [ticket:1729].
.c. attribute of a select().apply_labels()
is now based on <tablename>_<colkey> instead
of <tablename>_<colname>, for those columns
that have a distinctly named .key.
[ticket:2397]
- resolved some serious speed hits I missed, we need to ensure
only deannotated columns are used in the local/remote collections and soforth
so that hash lookups against mapped columns don't dig into __eq__()
- fix some other parity mismatches regarding stuff from [ticket:2453],
including finding another case where _deep_annotate() was doing the wrong thing,
new tests.
- [feature] Major rewrite of relationship()
internals now allow join conditions which
include columns pointing to themselves
within composite foreign keys. A new
API for very specialized primaryjoin conditions
is added, allowing conditions based on
SQL functions, CAST, etc. to be handled
by placing the annotation functions
remote() and foreign() inline within the
expression when necessary. Previous recipes
using the semi-private _local_remote_pairs
approach can be upgraded to this new
approach. [ticket:1401]
mechanics which could lead to incorrect
rendering of SELECT statements with aliases
and joins, particularly when using
column_property(). [ticket:2453]
condition with a "literal" in it would
raise an error on compile with certain
kinds of deeply nested expressions
which also needed to render the same
bound parameter name more than once.
[ticket:2425]
- using new traversal that returns the product of both sides
of a binary, starting to work with (a+b) == (c+d) types of joins.
primaryjoins on functions working
- annotations working, including reversing local/remote when
doing backref
of a Column as a string identifier in a
result set row. The .key is currently
listed as an "alternate" name for a column,
and is superseded by the name of a column
which has that key value as its regular name.
For the next major release
of SQLAlchemy we may reverse this precedence
so that .key takes precedence, but this
is not decided on yet. [ticket:2392]
against ORM-level column could be treated as
a distinct entity when producing certain
kinds of joined-inh joins. [ticket:2316]
- [bug] related to [ticket:2316], made some
adjustments to the change from [ticket:2261]
regarding the "from" list on a select(). The
_froms collection is no longer memoized, as this
simplifies various use cases and removes the
need for a "warning" if a column is attached
to a table after it was already used in an
expression - the select() construct will now
always produce the correct expression.
There's probably no real-world
performance hit here; select() objects are
almost always made ad-hoc, and systems that
wish to optimize the re-use of a select()
would be using the "compiled_cache" feature.
A hit which would occur when calling select.bind
has been reduced, but the vast majority
of users shouldn't be using "bound metadata"
anyway :).
so that generative methods work a bit better
off of cloned (this is almost a non-use case though).
In particular this allows with_only_columns()
to behave more consistently. Added additional
documentation to with_only_columns() to clarify
expected behavior, which changed as a result
of [ticket:2261]. [ticket:2319]
- document the crap out of with_only_columns, include caveats about
the change, etc.
dictionary to use a duck typing approach, i.e.
checks for "keys", to discern between update({})
and update((a, b)). Previously, passing a
dictionary that had tuples as keys would be misinterpreted
as a sequence. [ticket:2275]
for a select() element. The "from" calc is now
delayed, so that if the construct uses a Column
object that is not yet attached to a Table,
but is later associated with a Table, it generates
SQL using the table as a FROM. This change
impacted fairly deeply the mechanics of how
the FROM list as well as the "correlates" collection
is calculated, as some "clause adaption" schemes
(these are used very heavily in the ORM)
were relying upon the fact that the "froms"
collection would typically be cached before the
adaption completed. The rework allows it
such that the "froms" collection can be cleared
and re-generated at any time. [ticket:2261]
- RelationshipProperty.Comparator._criterion_exists()
adds an "_orm_adapt" annotation to the correlates target,
to work with the change in [ticket:2261]. It's not clear
if the change to correlation+adaption mechanics will affect end user
code yet.
- FromClause now uses group_expirable_memoized_property for
late-generated values like primary key, _columns, etc.
The Select class adds some tokens to this object and has the
nice effect that FromClause doesn't need to know about
Select's names anymore. An additional change might be to
have Select use a different group_expirable_memoized_property
so that it's collection of attribute names are specific to
Select though this isn't really necessary right now.
recursive descent with clone() + _copy_internals(). This is essentially
what it was doing anyway with lots of unnecessary steps.
Fix Alias() to honor the given clone() function which may have been the
reason the traversal hadn't been fixed sooner. Alias._copy_internals()
will specifically skip an alias of a Table
as a more specific form of what it was doing before. This may need to
be further improved such that ClauseAdapter or replacement_traverse()
send it some specific hints what not to dig into; **kw has been added
to all _copy_internals() to support this. replacement/clone traversal
is at least clear now.
- apply new no_replacement_traverse annotation to join created by
_create_joins(), fixes [ticket:2195]
- can replace orm.query "_halt_adapt" with "no_replacement_traverse"
determines what's in it's '.c' collection.
Behaves identically, except that a
raw ClauseList() passed to select([])
(which is not a documented case anyway) will
now be expanded into its individual column
elements instead of being ignored.
with another label in it would produce incorrect
exported columns. Among other things this would
break an ORM column_property() mapping against
another column_property(). [ticket:2167].
Also in 0.6.8
- _Label() is always against a column or selectable. remove
uncovered case of label against something else.
- start taking notes to clean up some of this labeling stuff,
which will be [ticket:2168]
conditions such that foreign key errors are
only considered between the two given tables.
That is, t1.join(t2) will report FK errors
that involve 't1' or 't2', but anything
involving 't3' will be skipped. This affects
join(), as well as ORM relationship and
inherit condition logic. Will keep the more conservative
approach to [ticket:2153] in 0.6.
whenever you say somecol.label(), now counts itself
in its "proxy_set" unioned with that of it's
contained column's proxy set, instead of
directly returning that of the contained column.
This allows column correspondence
operations which depend on the identity of the
_Labels themselves to return the correct result
- fixes ORM bug [ticket:1852].
a custom Column subclass can safely override
_constructor to return Column, for the purposes of
making "configurational" column classes that aren't
involved in proxying, etc.
if the left side is a join, it will attempt to join the right
side to the rightmost side of the left first, and not raise
any exceptions about ambiguous join conditions if successful
even if there are further join targets across the rest of
the left. [ticket:1714]
correspondence for cloned selectables which contain
free-standing column expressions. This bug is
generally only noticeable when exercising newer
ORM behavior only availble in 0.6 via [ticket:1568],
but is more correct at the SQL expression level
as well. [ticket:1617]
Mike Bayer