Skip to content

Commit

Permalink
Browse files Browse the repository at this point in the history
- changelog
fixes #21
  • Loading branch information
zzzeek committed Nov 9, 2014
1 parent 36fa6e4 commit 713b128
Show file tree
Hide file tree
Showing 2 changed files with 31 additions and 1 deletion.
30 changes: 30 additions & 0 deletions docs/build/changelog.rst
Expand Up @@ -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
Expand Down
2 changes: 1 addition & 1 deletion docs/build/tutorial.rst
Expand Up @@ -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.

Expand Down

0 comments on commit 713b128

Please sign in to comment.