From: Mike Bayer <mike_mp@zzzcomputing.com>
Date: Wed, 26 Jun 2013 17:24:07 +0000 (-0400)
Subject: Merge branch 'ticket_2746'
X-Git-Tag: rel_0_9_0b1~225
X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=f76e65727d667a0c40f132698c2c11063d7271bd;p=thirdparty%2Fsqlalchemy%2Fsqlalchemy.git

Merge branch 'ticket_2746'

Conflicts:
	doc/build/changelog/changelog_08.rst
	doc/build/changelog/changelog_09.rst
---

f76e65727d667a0c40f132698c2c11063d7271bd
diff --cc doc/build/changelog/changelog_08.rst
index f76d5c95c2,ba2450d55c..ef87fea453
--- a/doc/build/changelog/changelog_08.rst
+++ b/doc/build/changelog/changelog_08.rst
@@@ -7,13 -7,40 +7,47 @@@
      :version: 0.8.2
  
      .. change::
 +        :tags: bug, postgresql
 +        :tickets: 2767
 +
 +        Fixed bug where the order of columns in a multi-column
 +        Postgresql index would be reflected in the wrong order.
 +        Courtesy Roman Podolyaka.
 +
+         :tags: bug, sql
+         :tickets: 2746, 2668
+ 
+         Multiple fixes to the correlation behavior of
+         :class:`.Select` constructs, first introduced in 0.8.0:
+ 
+         * To satisfy the use case where FROM entries should be
+           correlated outwards to a SELECT that encloses another,
+           which then encloses this one, correlation now works
+           across multiple levels when explicit correlation is
+           established via :meth:`.Select.correlate`, provided
+           that the target select is somewhere along the chain
+           contained by a WHERE/ORDER BY/columns clause, not
+           just nested FROM clauses. This makes
+           :meth:`.Select.correlate` act more compatibly to
+           that of 0.7 again while still maintaining the new
+           "smart" correlation.
+ 
+         * When explicit correlation is not used, the usual
+           "implicit" correlation limits its behavior to just
+           the immediate enclosing SELECT, to maximize compatibility
+           with 0.7 applications, and also prevents correlation
+           across nested FROMs in this case, maintaining compatibility
+           with 0.8.0/0.8.1.
+ 
+         * The :meth:`.Select.correlate_except` method was not
+           preventing the given FROM clauses from correlation in
+           all cases, and also would cause FROM clauses to be incorrectly
+           omitted entirely (more like what 0.7 would do),
+           this has been fixed.
+ 
+         * Calling `select.correlate_except(None)` will enter
+           all FROM clauses into correlation as would be expected.
+ 
      .. change::
          :tags: bug, ext
  
diff --cc doc/build/changelog/changelog_09.rst
index 24a8e50845,abf0fde41a..57cf0da31a
--- a/doc/build/changelog/changelog_09.rst
+++ b/doc/build/changelog/changelog_09.rst
@@@ -7,13 -7,42 +7,49 @@@
      :version: 0.9.0
  
      .. change::
 +        :tags: bug, postgresql
 +        :tickets: 2767
 +
 +        Fixed bug where the order of columns in a multi-column
 +        Postgresql index would be reflected in the wrong order.
 +        Courtesy Roman Podolyaka.  Also in 0.8.2.
 +
+         :tags: bug, sql
+         :tickets: 2746, 2668
+ 
+         Multiple fixes to the correlation behavior of
+         :class:`.Select` constructs, first introduced in 0.8.0:
+ 
+         * To satisfy the use case where FROM entries should be
+           correlated outwards to a SELECT that encloses another,
+           which then encloses this one, correlation now works
+           across multiple levels when explicit correlation is
+           established via :meth:`.Select.correlate`, provided
+           that the target select is somewhere along the chain
+           contained by a WHERE/ORDER BY/columns clause, not
+           just nested FROM clauses. This makes
+           :meth:`.Select.correlate` act more compatibly to
+           that of 0.7 again while still maintaining the new
+           "smart" correlation.
+ 
+         * When explicit correlation is not used, the usual
+           "implicit" correlation limits its behavior to just
+           the immediate enclosing SELECT, to maximize compatibility
+           with 0.7 applications, and also prevents correlation
+           across nested FROMs in this case, maintaining compatibility
+           with 0.8.0/0.8.1.
+ 
+         * The :meth:`.Select.correlate_except` method was not
+           preventing the given FROM clauses from correlation in
+           all cases, and also would cause FROM clauses to be incorrectly
+           omitted entirely (more like what 0.7 would do),
+           this has been fixed.
+ 
+         * Calling `select.correlate_except(None)` will enter
+           all FROM clauses into correlation as would be expected.
+ 
+         Also in 0.8.2.
+ 
      .. change::
          :tags: bug, ext