Hello community,
here is the log from the commit of package python-alembic for openSUSE:Factory
checked in at 2019-09-23 12:46:41
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Comparing /work/SRC/openSUSE:Factory/python-alembic (Old)
and /work/SRC/openSUSE:Factory/.python-alembic.new.7948 (New)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Package is "python-alembic"
Mon Sep 23 12:46:41 2019 rev:46 rq:732612 version:1.2.0
Changes:
--------
--- /work/SRC/openSUSE:Factory/python-alembic/python-alembic.changes
2019-09-02 13:26:01.641304776 +0200
+++ /work/SRC/openSUSE:Factory/.python-alembic.new.7948/python-alembic.changes
2019-09-23 12:46:44.341517946 +0200
@@ -1,0 +2,79 @@
+Sat Sep 21 19:10:16 UTC 2019 - Arun Persaud <a...@gmx.de>
+
+- update to version 1.2.0:
+ * feature
+ + Added new --purge flag to the alembic stamp command, which will
+ unconditionally erase the version table before stamping
+ anything. This is useful for development where non-existent
+ version identifiers might be left within the table. Additionally,
+ alembic.stamp now supports a list of revision identifiers, which
+ are intended to allow setting up muliple heads at once. Overall
+ handling of version identifiers within the alembic.stamp command
+ has been improved with many new tests and use cases added.
+ References: #473
+ + Added new feature MigrationContext.autocommit_block(), a special
+ directive which will provide for a non-transactional block inside
+ of a migration script. The feature requres that: the database
+ driver (e.g. DBAPI) supports the AUTOCOMMIT isolation mode. The
+ directive also necessarily needs to COMMIT the existing
+ transaction in progress in order to enter autocommit mode. See
+ also MigrationContext.autocommit_block() References: #123
+ + Added “post write hooks” to revision generation. These allow
+ custom logic to run after a revision Python script is generated,
+ typically for the purpose of running code formatters such as
+ “Black” or “autopep8”, but may be used for any arbitrary
+ post-render hook as well, including custom Python functions or
+ scripts. The hooks are enabled by providing a [post_write_hooks]
+ section in the alembic.ini file. A single hook is provided which
+ runs an arbitrary Python executable on the newly generated
+ revision script, which can be configured to run code formatters
+ such as Black; full examples are included in the documentation.
+ See also Applying Post Processing and Python Code Formatters to
+ Generated Revisions References: #307
+ + Added new flag --package to alembic init. For environments where
+ the Alembic migration files and such are within the package tree
+ and importable as modules, this flag can be specified which will
+ add the additional __init__.py files in the version location and
+ the environment location. References: #463
+ * bug
+ + Improved the Python rendering of a series of migration
+ operations such that a single “pass” is rendered for a
+ UpgradeOps or DowngradeOps based on if no lines of Python code
+ actually rendered under the operation, rather than whether or
+ not sub-directives exist. Removed extra “pass” lines that would
+ generate from the ModifyTableOps directive so that these aren’t
+ duplicated under operation rewriting scenarios. References:
+ #550
+ + Fixed bug where rendering of comment text for table-level
+ comments within Operations.create_table_comment() and
+ Operations.drop_table_comment() was not properly quote-escaped
+ within rendered Python code for autogenerate. References: #549
+ + Modified the logic of the Rewriter object such that it keeps a
+ memoization of which directives it has processed, so that it can
+ ensure it processes a particular directive only once, and
+ additionally fixed Rewriter so that it functions correctly for
+ multiple-pass autogenerate schemes, such as the one illustrated
+ in the “multidb” template. By tracking which directives have
+ been processed, a multiple-pass scheme which calls upon the
+ Rewriter multiple times for the same structure as elements are
+ added can work without running duplicate operations on the same
+ elements more than once. References: #505
+ * usecase
+ + Added autogenerate support for Column objects that have
+ dialect-specific **kwargs, support first added in SQLAlchemy
+ 1.3. This includes SQLite “on conflict” as well as options used
+ by some third party dialects. References: #518
+ + Added rendering for SQLAlchemy Variant datatypes, which render
+ as the base type plus one or more .with_variant() method calls.
+ References: #131
+ + Made the command interface revision lookup behavior more strict
+ in that an Alembic revision number is only resolved based on a
+ partial match rules if it has at least four characters, to
+ prevent simple typographical issues from inadvertently running
+ migrations. References: #534
+ * misc
+ + Python 3.4 support is dropped, as the upstream tooling (pip,
+ mysqlclient) etc are already dropping support for Python 3.4,
+ which itself is no longer maintained.
+
+-------------------------------------------------------------------
Old:
----
alembic-1.1.0.tar.gz
New:
----
alembic-1.2.0.tar.gz
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Other differences:
------------------
++++++ python-alembic.spec ++++++
--- /var/tmp/diff_new_pack.WANCHe/_old 2019-09-23 12:46:44.829517865 +0200
+++ /var/tmp/diff_new_pack.WANCHe/_new 2019-09-23 12:46:44.833517865 +0200
@@ -18,7 +18,7 @@
%{?!python_module:%define python_module() python-%{**} python3-%{**}}
Name: python-alembic
-Version: 1.1.0
+Version: 1.2.0
Release: 0
Summary: A database migration tool for SQLAlchemy
License: MIT
++++++ alembic-1.1.0.tar.gz -> alembic-1.2.0.tar.gz ++++++
++++ 8716 lines of diff (skipped)
