From 1b7ffaa175775bb7d24b95fb39f7c3c052c23127 Mon Sep 17 00:00:00 2001 From: Mike Bayer Date: Thu, 20 Nov 2014 18:33:07 -0500 Subject: put the sqlite thing near the top as it's the other big feature --- docs/build/changelog.rst | 60 ++++++++++++++++++++++++------------------------ 1 file changed, 30 insertions(+), 30 deletions(-) diff --git a/docs/build/changelog.rst b/docs/build/changelog.rst index 9001333..3cc3026 100644 --- a/docs/build/changelog.rst +++ b/docs/build/changelog.rst @@ -26,6 +26,36 @@ Changelog :ref:`branches` + .. 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, commands @@ -86,36 +116,6 @@ Changelog :class:`~sqlalchemy.schema.Column` object specifies ``index=True``. Pull request courtesy David Szotten. - .. 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 -- cgit v1.2.1