- changelog

fixes #21

diff --git a/docs/build/changelog.rst b/docs/build/changelog.rst
index 9222a6bf227f14aa3d316a696c760a3bcc49771b..6b32648208bd6b2770bbdf7551ff37a4b3b5a019 100644 (file)
--- a/docs/build/changelog.rst
+++ b/docs/build/changelog.rst
@@ -5,6 +5,36 @@ Changelog
 .. changelog::
     :version: 0.7.0
 
+    .. change::
+      :tags: feature, operations, sqlite
+      :tickets: 21
+
+      Added "move and copy" workflow, where a table to be altered is copied to
+      a new one with the new structure and the old one dropped, is now
+      implemented for SQLite as well as all database backends in general
+      using the new :meth:`.Operations.batch_alter_table` system.   This
+      directive provides a table-specific operations context which gathers
+      column- and constraint-level mutations specific to that table, and
+      at the end of the context creates a new table combining the structure
+      of the old one with the given changes, copies data from old table to new,
+      and finally drops the old table,
+      renaming the new one to the existing name.  This is required for
+      fully featured SQLite migrations, as SQLite has very little support for the
+      traditional ALTER directive.   The batch directive
+      is intended to produce code that is still compatible with other databases,
+      in that the "move and copy" process only occurs for SQLite by default,
+      while still providing some level of sanity to SQLite's
+      requirement by allowing multiple table mutation operations to
+      proceed within one "move and copy" as well as providing explicit
+      control over when this operation actually occurs.  The "move and copy"
+      feature may be optionally applied to other backends as well, however
+      dealing with referential integrity constraints from other tables must
+      still be handled explicitly.
+
+      .. seealso::
+
+          :ref:`batch_migrations`
+
     .. change::
       :tags: feature, operations
       :tickets: 205

diff --git a/docs/build/tutorial.rst b/docs/build/tutorial.rst
index a4ae5176592084189ad1fd8aec1d294996343030..016e81b0bf664585792f592a514f471b2f1f1b1e 100644 (file)
--- a/docs/build/tutorial.rst
+++ b/docs/build/tutorial.rst
@@ -930,7 +930,7 @@ to be changed.
 Migration tools are instead expected to produce copies of SQLite tables that
 correspond to the new structure, transfer the data from the existing
 table to the new one, then drop the old table.  For our purposes here
-we'll call this **"move and copy" workflow**, and in order to accommodate it
+we'll call this **"move and copy"** workflow, and in order to accommodate it
 in a way that is reasonably predictable, while also remaining compatible
 with other databases, Alembic provides the **batch** operations context.