Hello community, here is the log from the commit of package python-alembic for openSUSE:Factory checked in at 2015-01-06 09:07:01 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Comparing /work/SRC/openSUSE:Factory/python-alembic (Old) and /work/SRC/openSUSE:Factory/.python-alembic.new (New) ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Package is "python-alembic" Changes: -------- --- /work/SRC/openSUSE:Factory/python-alembic/python-alembic.changes 2014-09-15 18:25:12.000000000 +0200 +++ /work/SRC/openSUSE:Factory/.python-alembic.new/python-alembic.changes 2015-01-06 09:07:18.000000000 +0100 @@ -1,0 +2,68 @@ +Mon Jan 5 10:19:27 UTC 2015 - [email protected] + +- update to 0.7.3: + * Fixed regression in new versioning system where upgrade / history + operation would fail on AttributeError if no version files were + present at all. + * Adjusted the SQLite backend regarding autogen of unique constraints + to work fully with the current SQLAlchemy 1.0, which now will report + on UNIQUE constraints that have no name. + * Fixed bug in batch where if the target table contained multiple + foreign keys to the same target table, the batch mechanics would + fail with a "table already exists" error. Thanks for the help + on this from Lucas Kahlert. + * Fixed an issue where the MySQL routine to skip foreign-key-implicit + indexes would also catch unnamed unique indexes, as they would be + named after the column and look like the FK indexes. Pull request + courtesy Johannes Erdfelt. + * Repaired a regression in both the MSSQL and Oracle dialects whereby + the overridden ``_exec()`` method failed to return a value, as is + needed now in the 0.7 series. + * The ``render_as_batch`` flag was inadvertently hardcoded to ``True``, + so all autogenerates were spitting out batch mode...this has been + fixed so that batch mode again is only when selected in env.py. + * Support for autogenerate of FOREIGN KEY constraints has been added. + These are delivered within the autogenerate process in the same + manner as UNIQUE constraints, including ``include_object`` support. + Big thanks to Ann Kamyshnikova for doing the heavy lifting here. + * Fixed bug where the "source_schema" argument was not correctly passed + when calling :meth:`.BatchOperations.create_foreign_key`. Pull + request courtesy Malte Marquarding. + * The "multiple heads / branches" feature has now landed. This is + by far the most significant change Alembic has seen since its inception; + while the workflow of most commands hasn't changed, and the format + of version files and the ``alembic_version`` table are unchanged as well, + a new suite of features opens up in the case where multiple version + files refer to the same parent, or to the "base". Merging of + branches, operating across distinct named heads, and multiple + independent bases are now all supported. The feature incurs radical + changes to the internals of versioning and traversal, and should be + treated as "beta mode" for the next several subsequent releases + within 0.7. + * 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. + * Relative revision identifiers as used with ``alembic upgrade``, + ``alembic downgrade`` and ``alembic history`` can be combined with + specific revisions as well, e.g. ``alembic upgrade ae10+3``, to produce + a migration target relative to the given exact version. + +------------------------------------------------------------------- Old: ---- alembic-0.6.7.tar.gz New: ---- alembic-0.7.3.tar.gz ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Other differences: ------------------ ++++++ python-alembic.spec ++++++ --- /var/tmp/diff_new_pack.8M6aeF/_old 2015-01-06 09:07:19.000000000 +0100 +++ /var/tmp/diff_new_pack.8M6aeF/_new 2015-01-06 09:07:19.000000000 +0100 @@ -1,7 +1,7 @@ # # spec file for package python-alembic # -# Copyright (c) 2014 SUSE LINUX Products GmbH, Nuernberg, Germany. +# Copyright (c) 2015 SUSE LINUX Products GmbH, Nuernberg, Germany. # # All modifications and additions to the file contributed by third parties # remain the property of their copyright owners, unless otherwise agreed @@ -17,7 +17,7 @@ Name: python-alembic -Version: 0.6.7 +Version: 0.7.3 Release: 0 Url: http://bitbucket.org/zzzeek/alembic Summary: A database migration tool for SQLAlchemy ++++++ alembic-0.6.7.tar.gz -> alembic-0.7.3.tar.gz ++++++ ++++ 33464 lines of diff (skipped) -- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
