commit python3-alembic for openSUSE:Factory
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 - toddrme2178@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)
participants (1)
-
root@hilbert.suse.de