From: Mike Bayer <mike_mp@zzzcomputing.com>
Date: Sat, 20 Sep 2014 19:06:05 +0000 (-0400)
Subject: - changelog for #197, fixes #197.
X-Git-Tag: rel_0_7_0~71
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=75652fe132913aea255e55d89b29c393283cdd06;p=thirdparty%2Fsqlalchemy%2Falembic.git

- changelog for #197, fixes #197.
---

diff --git a/docs/build/changelog.rst b/docs/build/changelog.rst
index 28091d65..a2c02397 100644
--- a/docs/build/changelog.rst
+++ b/docs/build/changelog.rst
@@ -5,6 +5,29 @@ Changelog
 .. changelog::
     :version: 0.7.0
 
+    .. change::
+      :tags: bug, autogenerate
+      :tickets: 197, 64, 196
+
+      The system by which autogenerate renders expressions within
+      a :class:`~sqlalchemy.schema.Index`, the ``server_default``
+      of :class:`~sqlalchemy.schema.Column`, and the
+      ``existing_server_default`` of
+      :meth:`.Operations.alter_column` has been overhauled to anticipate
+      arbitrary SQLAlchemy SQL constructs, such as ``func.somefunction()``,
+      ``cast()``, ``desc()``, and others.   The system does not, as might
+      be preferred, render the full-blown Python expression as originally
+      created within the application's source code, as this would be exceedingly
+      complex and difficult.  Instead, it renders the SQL expression against
+      the target backend that's subject to the autogenerate, and then
+      renders that SQL inside of a :func:`~sqlalchemy.sql.expression.text`
+      construct as a literal SQL string.  This approach still has the
+      downside that the rendered SQL construct may not be backend-agnostic
+      in all cases, so there is still a need for manual intervention in that
+      small number of cases, but overall the majority of cases should work
+      correctly now.  Big thanks to Carlos Rivera for pull requests and
+      support on this.
+
     .. change::
       :tags: feature