python/python-alembic
SHA256
15
0
Fork 0
forked from pool/python-alembic
Code Pull Requests Activity

Accepting request 267264 from devel:languages:python

Browse Source 
1

OBS-URL: https://build.opensuse.org/request/show/267264
OBS-URL: https://build.opensuse.org/package/show/openSUSE:Factory/python-alembic?expand=0&rev=17
This commit is contained in:
Dominique Leuenberger
2015-01-06 08:07:01 +00:00
committed by Git OBS Bridge
parent 435eb3369d f084d24ddb
commit de753263ff
4 changed files with 73 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3
alembic-0.6.7.tar.gz
View File

@@ -1,3 +0,0 @@
version https://git-lfs.github.com/spec/v1
oid sha256:55c35e897d2970bae45345ff4c8a190e773a08f4289299de694ebfebfb0c6946
size 467942

3
alembic-0.7.3.tar.gz Normal file
View File

@@ -0,0 +1,3 @@
version https://git-lfs.github.com/spec/v1
oid sha256:1d3302214bc50ff94dcb8def0f2208e50dcf7b5c120729eeb929711a70e8a112
size 601533

68
python-alembic.changes
View File

@@ -1,3 +1,71 @@
-------------------------------------------------------------------
Mon Jan 5 10:19:27 UTC 2015 - dmueller@suse.com
- 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.
-------------------------------------------------------------------
Mon Sep 15 05:25:46 UTC 2014 - tbechtold@suse.com

4
python-alembic.spec
View File

@@ -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