when presented with duplicate columns. The behavior of emitting a
warning and replacing the old column with the same name still
remains to some degree; the replacement in particular is to maintain
backwards compatibility. However, the replaced column still remains
associated with the ``c`` collection now in a collection ``._all_columns``,
which is used by constructs such as aliases and unions, to deal with
the set of columns in ``c`` more towards what is actually in the
list of columns rather than the unique set of key names. This helps
with situations where SELECT statements with same-named columns
are used in unions and such, so that the union can match the columns
up positionally and also there's some chance of :meth:`.FromClause.corresponding_column`
still being usable here (it can now return a column that is only
in selectable.c._all_columns and not otherwise named).
The new collection is underscored as we still need to decide where this
list might end up. Theoretically it
would become the result of iter(selectable.c), however this would mean
that the length of the iteration would no longer match the length of
keys(), and that behavior needs to be checked out.
fixes#2974
- add a bunch more tests for ColumnCollection
of columns given positionally would not be preserved. This could
have potential impact in positional situations such as applying the
resulting :class:`.TextAsFrom` object to a union.
Have also considered linking column.label() to the "column" itself being
in the result map but this reveals some naming collision problems (that
also seem to be very poorly tested...). This should be as far as
we want to go right now with [ticket:2932].
:class:`.Query` and in other situations where selects or joins
were aliased (such as joined table inheritance) could fail if a
user-defined :class:`.Column` subclass were used in the expression.
In this case, the subclass would fail to propagate ORM-specific
"annotations" along needed by the adaptation. The "expression
annotations" system has been corrected to account for this case.
[ticket:2918]
- move out tests, dialect specific out of compiler, compiler tests use new API,
legacy API tests in test_selecatble
- add support for adaptation of ForUpdateArg, alias support in compilers
:func:`.foreign` on a :class:`.Column` before association with a parent
:class:`.Table` could produce issues related to the parent table not
rendering within joins, due to the inherent copy operation performed
by an annotation. [ticket:2813]
form of a some expressions when referring to the ``.c`` collection
on a ``select()`` construct, but the ``str()`` form isn't available
since the element relies on dialect-specific compilation constructs,
notably the ``__getitem__()`` operator as used with a Postgresql
``ARRAY`` element. The fix also adds a new exception class
:class:`.UnsupportedCompilationError` which is raised in those cases
where a compiler is asked to compile something it doesn't know
how to. Also in 0.8.3.
[ticket:2780]
- 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.
target :class:`.Column` has been reworked to be as
immediate as possible, based on the moment that the
target :class:`.Column` is associated with the same
:class:`.MetaData` as this :class:`.ForeignKey`, rather
than waiting for the first time a join is constructed,
or similar. This along with other improvements allows
earlier detection of some foreign key configuration
issues. Also included here is a rework of the
type-propagation system, so that
it should be reliable now to set the type as ``None``
on any :class:`.Column` that refers to another via
:class:`.ForeignKey` - the type will be copied from the
target column as soon as that other column is associated,
and now works for composite foreign keys as well.
[ticket:1765]
foreign key paths to a table "B", to that table "B", would fail
to produce the "ambiguous join condition" error that would be
reported if you join table "A" directly to "B"; it would instead
produce a join condition with multiple criteria.
[ticket:2738]
labeled columns when apply_labels() is used; this mode
produces a SELECT where each column is labeled as in
<tablename>_<columnname>, to remove column name collisions
for a multiple table select. The fix is that if two labels
collide when combined with the table name, i.e.
"foo.bar_id" and "foo_bar.id", anonymous aliasing will be
applied to one of the dupes. This allows the ORM to handle
both columns independently; previously, 0.7
would in some cases silently emit a second SELECT for the
column that was "duped", and in 0.8 an ambiguous column error
would be emitted. The "keys" applied to the .c. collection
of the select() will also be deduped, so that the "column
being replaced" warning will no longer emit for any select()
that specifies use_labels, though the dupe key will be given
an anonymous label which isn't generally user-friendly.
[ticket:2702]
could impact some usages of the new :func:`.orm.remote` and
:func:`.orm.local` annotation functions, where annotations
could be lost when the column were used in a subsequent
expression.
[ticket:2660]
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 :).
Mike Bayer