Hello community,

here is the log from the commit of package python3-alembic for openSUSE:Factory 
checked in at 2016-01-23 01:16:24
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Comparing /work/SRC/openSUSE:Factory/python3-alembic (Old)
 and      /work/SRC/openSUSE:Factory/.python3-alembic.new (New)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Package is "python3-alembic"

Changes:
--------
--- /work/SRC/openSUSE:Factory/python3-alembic/python3-alembic.changes  
2015-08-03 17:21:42.000000000 +0200
+++ /work/SRC/openSUSE:Factory/.python3-alembic.new/python3-alembic.changes     
2016-01-23 01:16:29.000000000 +0100
@@ -1,0 +2,190 @@
+Wed Jan 13 13:40:38 UTC 2016 - toddrme2...@gmail.com
+
+- Update to 0.8.4
+  + feature
+    * A major improvement to the hash id generation function, which
+      for some reason used an awkward arithmetic formula against
+      uuid4() that produced values that tended to start with the
+      digits 1-4. Replaced with a simple substring approach which
+      provides an even distribution. Pull request courtesy
+      Antti Haapala.
+    * Added an autogenerate renderer for the ExecuteSQLOp operation
+      object; only renders if given a plain SQL string, otherwise
+      raises NotImplementedError. Can be of help with custom
+      autogenerate sequences that includes straight SQL execution.
+      Pull request courtesy Jacob Magnusson.
+  + bug
+    * Batch mode generates a FOREIGN KEY constraint that is
+      self-referential using the ultimate table name, rather than
+      _alembic_batch_temp. When the table is renamed from
+      _alembic_batch_temp back to the original name, the FK now
+      points to the right name. This will not work if referential
+      integrity is being enforced
+      (eg. SQLite “PRAGMA FOREIGN_KEYS=ON”) since the original table
+      is dropped and the new table then renamed to that name,
+      however this is now consistent with how foreign key constraints
+      on other tables already operate with batch mode; these don’t
+      support batch mode if referential integrity is enabled in any
+      case.
+    * Added a type-level comparator that distinguishes Integer,
+      BigInteger, and SmallInteger types and dialect-specific types;
+      these all have “Integer” affinity so previously all compared
+      as the same.
+    * Fixed bug where the server_default parameter of alter_column()
+      would not function correctly in batch mode.
+    * Adjusted the rendering for index expressions such that a
+      Column object present in the source Index will not be rendered
+      as table-qualified; e.g. the column name will be rendered alone.
+      Table-qualified names here were failing on systems such as
+      Postgresql.
+- Update to 0.8.3
+  + bug
+    * Fixed an 0.8 regression whereby the “imports” dictionary member
+      of the autogen context was removed; this collection is
+      documented in the “render custom type” documentation as a place
+      to add new imports. The member is now known as
+      AutogenContext.imports and the documentation is repaired.
+    * Fixed bug in batch mode where a table that had pre-existing
+      indexes would create the same index on the new table with the
+      same name, which on SQLite produces a naming conflict as index
+      names are in a global namespace on that backend. Batch mode
+      now defers the production of both existing and new indexes until
+      after the entire table transfer operation is complete, which
+      also means those indexes no longer take effect during the INSERT
+      from SELECT section as well; the indexes are applied in a single
+      step afterwards.
+    * Added “pytest-xdist” as a tox dependency, so that the -n flag in
+      the test command works if this is not already installed. Pull
+      request courtesy Julien Danjou.
+    * Fixed issue in PG server default comparison where model-side
+      defaults configured with Python unicode literals would leak the
+      “u” character from a repr() into the SQL used for comparison,
+      creating an invalid SQL expression, as the server-side comparison
+      feature in PG currently repurposes the autogenerate Python
+      rendering feature to get a quoted version of a plain string default.
+- Update to 0.8.2
+  + bug
+    * Added workaround in new foreign key option detection feature for
+      MySQL’s consideration of the “RESTRICT” option being the default,
+      for which no value is reported from the database; the MySQL impl
+      now corrects for when the model reports RESTRICT but the database
+      reports nothing. A similar rule is in the default FK comparison
+      to accommodate for the default “NO ACTION” setting being present
+      in the model but not necessarily reported by the database, or
+      vice versa.
+- Update to 0.8.1
+  + feature
+    * A custom EnvironmentContext.configure.process_revision_directives
+      hook can now generate op directives within the UpgradeOps and
+      DowngradeOps containers that will be generated as Python code
+      even when the --autogenerate flag is False; provided that
+      revision_environment=True, the full render operation will be run
+      even in “offline” mode.
+    * Implemented support for autogenerate detection of changes in the
+      ondelete, onupdate, initially and deferrable attributes of
+      ForeignKeyConstraint objects on SQLAlchemy backends that support
+      these on reflection (as of SQLAlchemy 1.0.8 currently Postgresql
+      for all four, MySQL for ondelete and onupdate only). A constraint
+      object that modifies these values will be reported as a “diff”
+      and come out as a drop/create of the constraint with the modified
+      values. The fields are ignored for backends which don’t reflect
+      these attributes (as of SQLA 1.0.8 this includes SQLite, Oracle,
+      SQL Server, others).
+  + bug
+    * Repaired the render operation for the ops.AlterColumnOp object
+      to succeed when the “existing_type” field was not present.
+    * Fixed a regression 0.8 whereby the “multidb” environment template
+      failed to produce independent migration script segments for the
+      output template. This was due to the reorganization of the script
+      rendering system for 0.8. To accommodate this change, the
+      MigrationScript structure will in the case of multiple calls to
+      MigrationContext.run_migrations() produce lists for the
+      MigrationScript.upgrade_ops and MigrationScript.downgrade_ops
+      attributes; each UpgradeOps and DowngradeOps instance keeps track
+      of its own upgrade_token and downgrade_token, and each are
+      rendered individually.
+- Update to 0.8.0
+  + feature
+    * Added new command alembic edit. This command takes the same
+      arguments as alembic show, however runs the target script file
+      within $EDITOR. Makes use of the python-editor library in order
+      to facilitate the handling of $EDITOR with reasonable default
+      behaviors across platforms. Pull request courtesy Michel Albert.
+    * Added new multiple-capable argument --depends-on to the alembic
+      revision command, allowing depends_on to be established at the
+      command line level rather than having to edit the file after the
+      fact. depends_on identifiers may also be specified as branch
+      names at the command line or directly within the migration file.
+      The values may be specified as partial revision numbers from the
+      command line which will be resolved to full revision numbers in
+      the output file.
+    * The default test runner via “python setup.py test” is now
+      py.test. nose still works via run_tests.py.
+    * The internal system for Alembic operations has been reworked to
+      now build upon an extensible system of operation objects. New
+      operations can be added to the op. namespace, including that they
+      are available in custom autogenerate schemes.
+    * The internal system for autogenerate been reworked to build upon
+      the extensible system of operation objects present in #302. As
+      part of this change, autogenerate now produces a full object graph
+      representing a list of migration scripts to be written as well as
+      operation objects that will render all the Python code within
+      them; a new hook
+      EnvironmentContext.configure.process_revision_directives allows
+      end-user code to fully customize what autogenerate will do,
+      including not just full manipulation of the Python steps to take
+      but also what file or files will be written and where.
+      Additionally, autogenerate is now extensible as far as database
+      objects compared and rendered into scripts; any new operation
+      directive can also be registered into a series of hooks that allow
+      custom database/model comparison functions to run as well as to
+      render new operation directives into autogenerate scripts.
+  + bug
+    * Fixed bug in batch mode where the batch_op.create_foreign_key()
+      directive would be incorrectly rendered with the source table and
+      schema names in the argument list.
+    * Fixed bug where in the erroneous case that alembic_version
+      contains duplicate revisions, some commands would fail to process
+      the version history correctly and end up with a KeyError. The fix
+      allows the versioning logic to proceed, however a clear error is
+      emitted later when attempting to update the alembic_version table.
+  + misc
+    * A range of positional argument names have been changed to be
+      clearer and more consistent across methods within the Operations
+      namespace. The most prevalent form of name change is that the
+      descriptive names constraint_name and table_name are now used where
+      previously the name name would be used. This is in support of the
+      newly modularized and extensible system of operation objects in
+      alembic.operations.ops. An argument translation layer is in place
+      across the alembic.op namespace that will ensure that named argument
+      calling styles that use the old names will continue to function by
+      transparently translating to the new names, also emitting a warning.
+      This, along with the fact that these arguments are positional in any
+      case and aren’t normally passed with an explicit name, should ensure
+      that the overwhelming majority of applications should be unaffected
+      by this change. The only applications that are impacted are those
+      that: use the Operations object directly in some way, rather than
+      calling upon the alembic.op namespace, and invoke the methods on
+      Operations using named keyword arguments for positional arguments
+      like table_name, constraint_name, etc., which commonly were named
+      name as of 0.7.6. any application that is using named keyword
+      arguments in place of positional argument for the recently added
+      BatchOperations object may also be affected.
+      The naming changes are documented as “versionchanged” for 0.8.0:
+      > BatchOperations.create_check_constraint()
+      > BatchOperations.create_foreign_key()
+      > BatchOperations.create_index()
+      > BatchOperations.create_unique_constraint()
+      > BatchOperations.drop_constraint()
+      > BatchOperations.drop_index()
+      > Operations.create_check_constraint()
+      > Operations.create_foreign_key()
+      > Operations.create_primary_key()
+      > Operations.create_index()
+      > Operations.create_table()
+      > Operations.create_unique_constraint()
+      > Operations.drop_constraint()
+      > Operations.drop_index()
+      > Operations.drop_table()
+
+-------------------------------------------------------------------

Old:
----
  alembic-0.7.7.tar.gz

New:
----
  alembic-0.8.4.tar.gz

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Other differences:
------------------
++++++ python3-alembic.spec ++++++
--- /var/tmp/diff_new_pack.Tw8kmq/_old  2016-01-23 01:16:30.000000000 +0100
+++ /var/tmp/diff_new_pack.Tw8kmq/_new  2016-01-23 01:16:30.000000000 +0100
@@ -1,7 +1,7 @@
 #
 # spec file for package python3-alembic
 #
-# Copyright (c) 2015 SUSE LINUX GmbH, Nuernberg, Germany.
+# Copyright (c) 2016 SUSE LINUX 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:           python3-alembic
-Version:        0.7.7
+Version:        0.8.4
 Release:        0
 Url:            https://pypi.python.org/pypi/alembic
 Summary:        A database migration tool for SQLAlchemy
@@ -27,14 +27,17 @@
 BuildRoot:      %{_tmppath}/%{name}-%{version}-build
 BuildRequires:  python3
 BuildRequires:  python3-devel
-BuildRequires:  python3-distribute
-# Test requirements:
+BuildRequires:  python3-setuptools
 BuildRequires:  python3-Mako
 BuildRequires:  python3-SQLAlchemy >= 0.7.6
+BuildRequires:  python3-python-editor >= 0.3
+# Test requirements:
 BuildRequires:  python3-mock
-BuildRequires:  python3-nose >= 0.11
+BuildRequires:  python3-pytest
+BuildRequires:  python3-pytest-cov
 Requires:       python3-Mako
 Requires:       python3-SQLAlchemy >= 0.7.6
+Requires:       python3-python-editor >= 0.3
 Requires(post): update-alternatives
 Requires(postun): update-alternatives
 BuildArch:      noarch

++++++ alembic-0.7.7.tar.gz -> alembic-0.8.4.tar.gz ++++++
++++ 40613 lines of diff (skipped)


Reply via email to