python-alembic-0.9.9-bp150.1.3

- update to version 0.9.9:
  * feature
    + [feature] [commands] Added new flag --indicate-current to the
    alembic history command. When listing versions, it will include
    the token ?(current)? to indicate the given version is a current
    head in the target database. Pull request courtesy Kazutaka
    Mise.  References: #481
  * bug
    + [bug] [autogenerate] [mysql] The fix for #455 in version 0.9.6
    involving MySQL server default comparison was entirely non
    functional, as the test itself was also broken and didn?t reveal
    that it wasn?t working. The regular expression to compare server
    default values like CURRENT_TIMESTAMP to current_timestamp() is
    repaired.  References: #455
    + [bug] [autogenerate] [mysql] Fixed bug where MySQL server
    default comparisons were basically not working at all due to
    incorrect regexp added in #455. Also accommodates for MariaDB
    10.2 quoting differences in reporting integer based server
    defaults.  References: #483
    + [bug] [mysql] [operations] Fixed bug in op.drop_constraint() for
    MySQL where quoting rules would not be applied to the constraint
    name.  References: #487

- update to version 0.9.8:
  * [bug] [runtime] Fixed bug where the Script.as_revision_number()
    method did not accommodate for the ?heads? identifier, which in
    turn caused the EnvironmentContext.get_head_revisions() and
    EnvironmentContext.get_revision_argument() methods to be not
    usable when multiple heads were present. The
    :meth:.`EnvironmentContext.get_head_revisions` method returns a
    tuple in all cases as documented. References: #482
  * [bug] [autogenerate] [postgresql] Fixed bug where autogenerate of
    ExcludeConstraint would render a raw quoted name for a Column that
    has case-sensitive characters, which when invoked as an inline
    member of the Table would produce a stack trace that the quoted
    name is not found. An incoming Column object is now rendered as
    sa.column('name'). References: #478
  * [bug] [autogenerate] Fixed bug where the indexes would not be
    included in a migration that was dropping the owning table. The
    fix now will also emit DROP INDEX for the indexes ahead of time,
    but more importantly will include CREATE INDEX in the downgrade
    migration. References: #468
  * [bug] [postgresql] Fixed the autogenerate of the module prefix
    when rendering the text_type parameter of postgresql.HSTORE, in
    much the same way that we do for ARRAY?s type and JSON?s
    text_type. References: #480
  * [bug] [mysql] Added support for DROP CONSTRAINT to the MySQL
    Alembic dialect to support MariaDB 10.2 which now has real CHECK
    constraints. Note this change does not add autogenerate support,
    only support for op.drop_constraint() to work. References: #479

- specfile:
  * update copyright year
- update to version 0.9.7:
  * [bug] [autogenerate] Fixed regression caused by #421 which would
    cause case-sensitive quoting rules to interfere with the
    comparison logic for index names, thus causing indexes to show as
    added for indexes that have case-sensitive names. Works with
    SQLAlchemy 0.9 and later series.
  * [bug] [autogenerate] [postgresql] Fixed bug where autogenerate
    would produce a DROP statement for the index implicitly created by
    a Postgresql EXCLUDE constraint, rather than skipping it as is the
    case for indexes implicitly generated by unique constraints. Makes
    use of SQLAlchemy 1.0.x?s improved ?duplicates index? metadata and
    requires at least SQLAlchemy version 1.0.x to function correctly.

- specfile:
  * added fdupes
- update to version 0.9.6:
  * feature
    + [feature] [commands] The alembic history command will now make
    use of the revision environment env.py unconditionally if the
    revision_environment configuration flag is set to
    True. Previously, the environment would only be invoked if the
    history specification were against a database-stored revision
    token. References: #447
  * bug
  * [bug] [commands] Fixed a few Python3.6 deprecation warnings by
    replacing StopIteration with return, as well as using
    getfullargspec() instead of getargspec() under Python 3.
    References: #458
  * [bug] [commands] An addition to #441 fixed in 0.9.5, we forgot to
    also filter for the + sign in migration names which also breaks
    due to the relative migrations feature.  References: #441
  * [bug] [autogenerate] Fixed bug expanding upon the fix for #85
    which adds the correct module import to the ?inner? type for an
    ARRAY type, the fix now accommodates for the generic
    sqlalchemy.types.ARRAY type added in SQLAlchemy 1.1, rendering the
    inner type correctly regardless of whether or not the Postgresql
    dialect is present.  References: #442
  * [bug] [mysql] Fixed bug where server default comparison of
    CURRENT_TIMESTAMP would fail on MariaDB 10.2 due to a change in
    how the function is represented by the database during reflection.
    References: #455
  * [bug] [autogenerate] Fixed bug where comparison of Numeric types
    would produce a difference if the Python-side Numeric
    inadvertently specified a non-None ?scale? with a ?precision? of
    None, even though this Numeric type will pass over the ?scale?
    argument when rendering. Pull request courtesy Ivan Mmelnychuk.
    References: pull request bitbucket:70
  * [bug] [batch] The name of the temporary table in batch mode is now
    generated off of the original table name itself, to avoid
    conflicts for the unusual case of multiple batch operations
    running against the same database schema at the same time.
    References: #457
  * [bug] [autogenerate] A ForeignKeyConstraint can now render
    correctly if the link_to_name flag is set, as it will not attempt
    to resolve the name from a ?key? in this case. Additionally, the
    constraint will render as-is even if the remote column name isn?t
    present on the referenced remote table.  References: #456
  * [bug] [runtime] [py3k] Reworked ?sourceless? system to be fully
    capable of handling any combination of: Python2/3x, pep3149 or
    not, PYTHONOPTIMIZE or not, for locating and loading both env.py
    files as well as versioning files. This includes: locating files
    inside of __pycache__ as well as listing out version files that
    might be only in versions/__pycache__, deduplicating version files
    that may be in versions/__pycache__ and versions/ at the same
    time, correctly looking for .pyc or .pyo files based on if pep488
    is present or not. The latest Python3x deprecation warnings
    involving importlib are also corrected.

- update to 0.9.5:
  * see http://alembic.zzzcomputing.com/en/latest/changelog.html#change-0.8.8
  * see http://alembic.zzzcomputing.com/en/latest/changelog.html#change-0.8.9
  * see http://alembic.zzzcomputing.com/en/latest/changelog.html#change-0.8.10
  * see http://alembic.zzzcomputing.com/en/latest/changelog.html#change-0.9.0
  * see http://alembic.zzzcomputing.com/en/latest/changelog.html#change-0.9.1
  * see http://alembic.zzzcomputing.com/en/latest/changelog.html#change-0.9.2
  * see http://alembic.zzzcomputing.com/en/latest/changelog.html#change-0.9.3
  * see http://alembic.zzzcomputing.com/en/latest/changelog.html#change-0.9.4
  * see http://alembic.zzzcomputing.com/en/latest/changelog.html#change-0.9.5
- convert to singlespec
- split -doc package

- Update to 0.8.10:
  * various bugfixes

- update to 0.8.7:
  - Fixed bug where upgrading to the head of a branch which is already
    present would fail, only if that head were also the dependency
    of a different branch that is also upgraded, as the revision system
    would see this as trying to go in the wrong direction.   The check
    here has been refined to distinguish between same-branch revisions
    out of order vs. movement along sibling branches.
  - Adjusted the version traversal on downgrade
    such that we can downgrade to a version that is a dependency for
    a version in a different branch, *without* needing to remove that
    dependent version as well.  Previously, the target version would be
    seen as a "merge point" for it's normal up-revision as well as the
    dependency.  This integrates with the changes for :ticket:`377`
    and :ticket:`378` to improve treatment of branches with dependencies
    overall.
  - Fixed bug where a downgrade to a version that is also a dependency
    to a different branch would fail, as the system attempted to treat
    this as an "unmerge" of a merge point, when in fact it doesn't have
    the other side of the merge point available for update.
  - Fixed bug where the "alembic current" command wouldn't show a revision
    as a current head if it were also a dependency of a version in a
    different branch that's also applied.   Extra logic is added to
    extract "implied" versions of different branches from the top-level
    versions listed in the alembic_version table.
  - Fixed bug where a repr() or str() of a Script object would fail
    if the script had multiple dependencies.
  - Fixed bug in autogen where if the DB connection sends the default
    schema as "None", this "None" would be removed from the list of
    schemas to check if include_schemas were set.  This could possibly
    impact using include_schemas with SQLite.
  - Small adjustment made to the batch handling for reflected CHECK
    constraints to accommodate for SQLAlchemy 1.1 now reflecting these.
    Batch mode still does not support CHECK constraints from the reflected
    table as these can't be easily differentiated from the ones created
    by types such as Boolean.

- fix source url

- update to 0.8.6:
  - Errors which occur within the Mako render step are now intercepted
    and raised as CommandErrors like other failure cases; the Mako
    exception itself is written using template-line formatting to
    a temporary file which is named in the exception message.
  - Added a fix to Postgresql server default comparison which first checks
    if the text of the default is identical to the original, before attempting
    to actually run the default.  This accomodates for default-generation
    functions that generate a new value each time such as a uuid function.
  - Fixed bug introduced by the fix for :ticket:`338` in version 0.8.4
    where a server default could no longer be dropped in batch mode.
    Pull request courtesy Martin Domke.
  - Fixed bug where SQL Server arguments for drop_column() would not
    be propagated when running under a batch block.  Pull request
    courtesy Michal Petrucha.

- update to 0.8.5:
  - Fixed bug where the columns rendered in a ``PrimaryKeyConstraint``
    in autogenerate would inappropriately render the "key" of the
    column, not the name.  Pull request courtesy Jesse Dhillon.
  - Repaired batch migration support for "schema" types which generate
    constraints, in particular the ``Boolean`` datatype which generates
    a CHECK constraint.  Previously, an alter column operation with this
    type would fail to correctly accommodate for the CHECK constraint
    on change both from and to this type.  In the former case the operation
    would fail entirely, in the latter, the CHECK constraint would
    not get generated.  Both of these issues are repaired.
  - Changing a schema type such as ``Boolean`` to a non-schema type would
    emit a drop constraint operation which emits ``NotImplementedError`` for
    the MySQL dialect.  This drop constraint operation is now skipped when
    the constraint originates from a schema type.
  - 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 :class:`.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.
  - 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 :class:`.Integer`,
    :class:`.BigInteger`, and :class:`.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 :class:`.Column`
    object present in the source :class:`.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.
  - 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
    :attr:`.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:
  - 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.
  - 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).
  - 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:
  - 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.
  - 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.
  - Implemented support for BatchOperations.create_primary_key() and
    BatchOperations.create_check_constraint(). Additionally, table keyword
    arguments are copied from the original reflected table, such as the
    ?mysql_engine? keyword argument.
  - Fixed critical issue where a complex series of branches/merges would
    bog down the iteration algorithm working over redundant nodes for millions
    of cycles. An internal adjustment has been made so that duplicate nodes are
    skipped within this iteration.
  - The MigrationContext.stamp() method, added as part of the versioning
    refactor in 0.7 as a more granular version of command.stamp(), now includes
    the ?create the alembic_version table if not present? step in the same
    way as the command version, which was previously omitted.
  - Fixed bug where foreign key options including ?onupdate?, ?ondelete? would
    not render within the op.create_foreign_key() directive, even though they
    render within a full ForeignKeyConstraint directive.
  - Repaired warnings that occur when running unit tests against SQLAlchemy
    1.0.5 or greater involving the ?legacy_schema_aliasing? flag.
- Add python-pytest-cov as BuildRequires
- Add python-python-editor as Requires and BuildRequires

- fix rhel deps by depending on /usr/sbin/update-alternatives

- update to 0.7.7:
  * Implemented support for BatchOperations.create_primary_key()
    and BatchOperations.create_check_constraint(). Additionally,
    table keyword arguments are copied from the original reflected
    table, such as the "mysql_engine" keyword argument.
  * Fixed critical issue where a complex series of branches/merges
    would bog down the iteration algorithm working over redundant
    nodes for millions of cycles. An internal adjustment has been
    made so that duplicate nodes are skipped within this iteration.
  * The MigrationContext.stamp() method, added as part of the
    versioning refactor in 0.7 as a more granular version of
    command.stamp(), now includes the ?create the alembic_version
    table if not present? step in the same way as the command
    version, which was previously omitted.
  * Fixed bug where foreign key options including "onupdate",
    "ondelete" would not render within the op.create_foreign_key()
    directive, even though they render within a full
    ForeignKeyConstraint directive.
  * Repaired warnings that occur when running unit tests against
    SQLAlchemy 1.0.5 or greater involving the
    "legacy_schema_aliasing" flag.

- update to 0.7.6:
  * Fixed bug where the case of multiple mergepoints that all
    have the identical set of ancestor revisions would fail to be
    upgradable, producing an assertion failure.
  * Added support for type comparison functions to be not just per
    environment, but also present on the custom types themselves, by
    supplying a method ``compare_against_backend``.
  * Fully implemented the :paramref:`~.Operations.batch_alter_table.copy_from`
    parameter for batch mode
  * Repaired support for the :meth:`.BatchOperations.create_index`
    directive, which was mis-named internally such that the operation

- update to 0.7.5.post2:
  * Added a new feature Config.attributes, to help with the use
    case of sharing state such as engines and connections on the
    outside with a series of Alembic API calls; also added a new
    cookbook section to describe this simple but pretty important
    use case.
  * The format of the default env.py script has been refined a bit;
    it now uses context managers not only for the scope of the
    transaction, but also for connectivity from the starting
    engine. The engine is also now called a ?connectable? in
    support of the use case of an external connection being passed
    in.
  * Added support for ?alembic stamp? to work when given ?heads? as
    an argument, when multiple heads are present.
  * The --autogenerate option is not valid when used in conjunction
    with ?offline? mode, e.g. --sql. This now raises a
    CommandError, rather than failing more deeply later on. Pull
    request courtesy Johannes Erdfelt.
  * Fixed bug where the mssql DROP COLUMN directive failed to
    include modifiers such as ?schema? when emitting the DDL.
  * Postgresql ?functional? indexes are necessarily skipped from
    the autogenerate process, as the SQLAlchemy backend currently
    does not support reflection of these structures. A warning is
    emitted both from the SQLAlchemy backend as well as from the
    Alembic backend for Postgresql when such an index is detected.
  * Fixed bug where MySQL backend would report dropped unique
    indexes and/or constraints as both at the same time. This is
    because MySQL doesn?t actually have a ?unique constraint?
    construct that reports differently than a ?unique index?, so it
    is present in both lists. The net effect though is that the
    MySQL backend will report a dropped unique index/constraint as
    an index in cases where the object was first created as a
    unique constraint, if no other information is available to make
    the decision. This differs from other backends like Postgresql
    which can report on unique constraints and unique indexes
    separately.
  * Fixed bug where using a partial revision identifier as the
    ?starting revision? in --sql mode in a downgrade operation
    would fail to resolve properly.
- set minimum version for SQLAlchemy to 0.7.6
- use update-alternatives for alembic binary
- always run the tests when building the package

- update to 0.7.4:
  * Repaired issue where a server default specified without text()
  that represented a numeric or floating point (e.g. with decimal
  places) value would fail in the Postgresql-specific check for
  ?compare server default?; as PG accepts the value with quotes
  in the table specification, it?s still valid. Pull request
  courtesy Dimitris Theodorou.
  * The rendering of a ForeignKeyConstraint will now ensure that
  the names of the source and target columns are the database-side
  name of each column, and not the value of the .key attribute as
  may be set only on the Python side. This is because Alembic
  generates the DDL for constraints as standalone objects without
  the need to actually refer to an in-Python Table object, so
  there?s no step that would resolve these Python-only key names
  to database column names.
  * Fixed bug in foreign key autogenerate where if the in-Python
  table used custom column keys (e.g. using the key='foo' kwarg
  to Column), the comparison of existing foreign keys to those
  specified in the metadata would fail, as the reflected table
  would not have these keys available which to match up. Foreign
  key comparison for autogenerate now ensures it?s looking at
  the database-side names of the columns in all cases; this
  matches the same functionality within unique constraints and
  indexes.
  * Fixed issue in autogenerate type rendering where types that
  belong to modules that have the name ?sqlalchemy? in them would
  be mistaken as being part of the sqlalchemy. namespace. Pull
  req courtesy Bartosz Burclaf.

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

- update to version 0.6.7:
  * See
    + http://alembic.readthedocs.org/en/latest/changelog.html#change-0.6.6
    + http://alembic.readthedocs.org/en/latest/changelog.html#change-0.6.7
  * Fixed bug in MSSQL dialect where "rename table" wasn't using
    ``sp_rename()`` as is required on SQL Server.  Pull request courtesy
  * Added support for functional indexes when using the
    :meth:`.Operations.create_index` directive.   Within the list of columns,
    the SQLAlchemy ``text()`` construct can be sent, embedding a literal
    SQL expression; the :meth:`.Operations.create_index` will perform some
    hackery behind the scenes to get the :class:`.Index` construct to cooperate.
    This works around some current limitations in :class:`.Index`
    which should be resolved on the SQLAlchemy side at some point.
  * A file named ``__init__.py`` in the ``versions/`` directory is now
    ignored by Alembic when the collection of version files is retrieved.
    Pull request courtesy Michael Floering.
  * Fixed Py3K bug where an attempt would be made to sort None against
    string values when autogenerate would detect tables across multiple
    schemas, including the default schema.  Pull request courtesy
    paradoxxxzero.
  * Autogenerate render will render the arguments within a Table construct
    using ``*[...]`` when the number of columns/elements is greater than
    255.  Pull request courtesy Ryan P. Kelly.
  * Fixed bug where foreign key constraints would fail to render in
    autogenerate when a schema name was present.  Pull request courtesy
    Andreas Zeidler.
  * Some deep-in-the-weeds fixes to try to get "server default" comparison
    working better across platforms and expressions, in particular on
    the Postgresql backend, mostly dealing with quoting/not quoting of various
    expressions at the appropriate time and on a per-backend basis.
    Repaired and tested support for such defaults as Postgresql interval
    and array defaults.
  * When a run of Alembic command line fails due to ``CommandError``,
    the output now prefixes the string with ``"FAILED:"``, and the error
    is also written to the log output using ``log.error()``.
  * Liberalized even more the check for MySQL indexes that shouldn't be
    counted in autogenerate as "drops"; this time it's been reported
    that an implicitly created index might be named the same as a composite
    foreign key constraint, and not the actual columns, so we now skip those
    when detected as well.
  * Added a new accessor :attr:`.MigrationContext.config`, when used
    in conjunction with a :class:`.EnvironmentContext` and
    :class:`.Config`, this config will be returned.  Patch
    courtesy Marc Abramowitz.

- update to 0.6.5:
  * See http://alembic.readthedocs.org/en/latest/changelog.html#change-0.6.5
  * Added new argument EnvironmentContext.configure.user_module_prefix
  * The ScriptDirectory system that loads migration files from a
    versions/ directory
  * The command.revision() command now returns the Script object
    corresponding to the newly generated revision
  * Added new feature
    EnvironmentContext.configure.transaction_per_migration, which when True
    causes the BEGIN/COMMIT pair to incur for each migration individually