summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMike Bayer <mike_mp@zzzcomputing.com>2014-11-09 16:27:11 -0500
committerMike Bayer <mike_mp@zzzcomputing.com>2014-11-09 16:27:11 -0500
commit713b128df48ba4ea638bb34b563bcfe10bbcf16f (patch)
tree0011fe565120e2daf6a3daf39fb4a7b28db39a50
parent36fa6e4603ba19d6c27b4e4c728a30effa72fdc0 (diff)
downloadalembic-batch_alter.tar.gz
- changelogbatch_alter
fixes #21
-rw-r--r--docs/build/changelog.rst30
-rw-r--r--docs/build/tutorial.rst2
2 files changed, 31 insertions, 1 deletions
diff --git a/docs/build/changelog.rst b/docs/build/changelog.rst
index 9222a6b..6b32648 100644
--- a/docs/build/changelog.rst
+++ b/docs/build/changelog.rst
@@ -6,6 +6,36 @@ 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 a4ae517..016e81b 100644
--- 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.