From 7f0ee900b6c35a9bff214f9ebb02c3fb98d1f7e1 Mon Sep 17 00:00:00 2001 From: Mike Bayer Date: Sat, 20 Apr 2013 03:09:10 -0400 Subject: [PATCH] - this issue is a bug, mention the apply_labels issue sooner --- doc/build/changelog/changelog_08.rst | 43 ++++++++++++++-------------- 1 file changed, 22 insertions(+), 21 deletions(-) diff --git a/doc/build/changelog/changelog_08.rst b/doc/build/changelog/changelog_08.rst index bdba906bb5..2a2925726c 100644 --- a/doc/build/changelog/changelog_08.rst +++ b/doc/build/changelog/changelog_08.rst @@ -7,7 +7,7 @@ :version: 0.8.1 .. change:: - :tags: bug + :tags: bug, orm :tickets: 2708 Improved the behavior of instance management regarding @@ -22,6 +22,27 @@ cycles too. A warning has been added when a class with a `__del__()` method is mapped. + .. change:: + :tags: bug, sql + :tickets: 2702 + + 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 + _, 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. + .. change:: :tags: bug, mysql :pullreq: 54 @@ -118,26 +139,6 @@ handling routine fails and regardless of whether the condition is a disconnect or not. - .. change:: - :tags: bug, sql - :tickets: 2702 - - 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 - _, 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. .. change:: :tags: bug, orm, declarative -- 2.47.3