]> git.ipfire.org Git - thirdparty/sqlalchemy/sqlalchemy.git/commit
A major fix to the way in which a select() object produces
authorMike Bayer <mike_mp@zzzcomputing.com>
Thu, 11 Apr 2013 20:14:23 +0000 (16:14 -0400)
committerMike Bayer <mike_mp@zzzcomputing.com>
Thu, 11 Apr 2013 20:14:23 +0000 (16:14 -0400)
commita5ede47f1225ac10e69e2624038424b013d6144f
tree687ee8c1e5ee28debc2a308cf67086ebdd2e0559
parentfa8c87eceb643f54a135b73e332a737ddd731af0
A major fix to the way in which a select() object produces
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]
doc/build/changelog/changelog_08.rst
lib/sqlalchemy/engine/result.py
lib/sqlalchemy/sql/compiler.py
lib/sqlalchemy/sql/expression.py
lib/sqlalchemy/util/_collections.py
test/aaa_profiling/test_compiler.py
test/orm/test_froms.py
test/profiles.txt
test/sql/test_query.py
test/sql/test_selectable.py