Skip to content

0.6.4
Compare
Choose a tag to compare
@sqla-tester sqla-tester released this 17 Sep 22:10
rel_0_6_4
e5a066c

0.6.4

Released: March 28, 2014

  • [bug] [mssql] Added quoting to the table name when the special EXEC is run to
    drop any existing server defaults or constraints when the
    drop_column.mssql_drop_check or
    drop_column.mssql_drop_default
    arguments are used.

    References: #186

  • [bug] [mysql] Added/fixed support for MySQL "SET DEFAULT" / "DROP DEFAULT" phrases,
    which will now be rendered if only the server default is changing
    or being dropped (e.g. specify None to alter_column() to indicate
    "DROP DEFAULT"). Also added support for rendering MODIFY rather than
    CHANGE when the column name isn't changing.

    References: #103

  • [bug] Added support for the initially, match keyword arguments
    as well as dialect-specific keyword arguments to
    Operations.create_foreign_key().

    tagsfeature

    tickets163

    Altered the support for "sourceless" migration files (e.g. only
    .pyc or .pyo present) so that the flag "sourceless=true" needs to
    be in alembic.ini for this behavior to take effect.

    References: #190

  • [bug] [mssql] The feature that keeps on giving, index/unique constraint autogenerate
    detection, has even more fixes, this time to accommodate database dialects
    that both don't yet report on unique constraints, but the backend
    does report unique constraints as indexes. The logic
    Alembic uses to distinguish between "this is an index!" vs.
    "this is a unique constraint that is also reported as an index!" has now
    been further enhanced to not produce unwanted migrations when the dialect
    is observed to not yet implement get_unique_constraints() (e.g. mssql).
    Note that such a backend will no longer report index drops for unique
    indexes, as these cannot be distinguished from an unreported unique
    index.

    References: #185

  • [bug] Extensive changes have been made to more fully support SQLAlchemy's new
    naming conventions feature. Note that while SQLAlchemy has added this
    feature as of 0.9.2, some additional fixes in 0.9.4 are needed to
    resolve some of the issues:

    -   The `Operations` object now takes into account the naming
    conventions that are present on the `MetaData` object that's
    associated using `~.EnvironmentContext.configure.target_metadata`.
    When `Operations` renders a constraint directive like
    `ADD CONSTRAINT`, it now will make use of this naming convention
    when it produces its own temporary `MetaData` object.

-   Note however that the autogenerate feature in most cases generates
    constraints like foreign keys and unique constraints with the
    final names intact; the only exception are the constraints implicit
    with a schema-type like Boolean or Enum.  In most of these cases,
    the naming convention feature will not take effect for these constraints
    and will instead use the given name as is, with one exception....

-   Naming conventions which use the `"%(constraint_name)s"` token, that
    is, produce a new name that uses the original name as a component,
    will still be pulled into the naming convention converter and be
    converted.  The problem arises when autogenerate renders a constraint
    with it's already-generated name present in the migration file's source
    code, the name will be doubled up at render time due to the combination
    of #1 and #2.  So to work around this, autogenerate now renders these
    already-tokenized names using the new `Operations.f()` component.
    This component is only generated if **SQLAlchemy 0.9.4** or greater
    is in use.

    Therefore it is highly recommended that an upgrade to Alembic 0.6.4
    be accompanied by an upgrade of SQLAlchemy 0.9.4, if the new naming
    conventions feature is used.

    References: #183

  • [bug] Suppressed IOErrors which can raise when program output pipe
    is closed under a program like head; however this only
    works on Python 2. On Python 3, there is not yet a known way to
    suppress the BrokenPipeError warnings without prematurely terminating
    the program via signals.

    References: #160

  • [bug] Fixed bug where Operations.bulk_insert() would not function
    properly when Operations.inline_literal() values were used,
    either in --sql or non-sql mode. The values will now render
    directly in --sql mode. For compatibility with "online" mode,
    a new flag ~.Operations.bulk_insert.multiinsert
    can be set to False which will cause each parameter set to be
    compiled and executed with individual INSERT statements.

    References: #179

  • [bug] [py3k] Fixed a failure of the system that allows "legacy keyword arguments"
    to be understood, which arose as of a change in Python 3.4 regarding
    decorators. A workaround is applied that allows the code to work
    across Python 3 versions.

    References: #175

  • [feature] The command.revision() command now returns the Script
    object corresponding to the newly generated revision. From this
    structure, one can get the revision id, the module documentation,
    and everything else, for use in scripts that call upon this command.
    Pull request courtesy Robbie Coomber.

Assets 2
Loading