From: Mike Bayer <mike_mp@zzzcomputing.com>
Date: Sat, 20 Apr 2013 07:09:10 +0000 (-0400)
Subject: - this issue is a bug, mention the apply_labels issue sooner
X-Git-Tag: rel_0_8_1~13^2
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=7f0ee900b6c35a9bff214f9ebb02c3fb98d1f7e1;p=thirdparty%2Fsqlalchemy%2Fsqlalchemy.git

- this issue is a bug, mention the apply_labels issue sooner
---

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
+      <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.
+
     .. 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
-      <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.
 
     .. change::
       :tags: bug, orm, declarative