update to latest version

• Files Changed
• Browse Source

baserev update by copy to link target

• Files Changed
• Browse Source

update to latest version

• Files Changed
• Browse Source

baserev update by copy to link target

• Files Changed
• Browse Source

update to latest version

• Files Changed
• Browse Source

baserev update by copy to link target

• Files Changed
• Browse Source

- 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

• Files Changed
• Browse Source

baserev update by copy to link target

• Files Changed
• Browse Source

- Update to 0.8.10:
  * various bugfixes

• Files Changed
• Browse Source

baserev update by copy to link target

• Files Changed
• Browse Source

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

• Files Changed
• Browse Source

baserev update by copy to link target

• Files Changed
• Browse Source

- fix source url

• Files Changed
• Browse Source

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

• Files Changed
• Browse Source

baserev update by copy to link target

• Files Changed
• Browse Source

- 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

• Files Changed
• Browse Source

baserev update by copy to link target

• Files Changed
• Browse Source

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

• Files Changed
• Browse Source

- 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

• Files Changed
• Browse Source

baserev update by copy to link target

• Files Changed
• Browse Source