0.8.8

0.8.8

Released: September 12, 2016

• [autogenerate] The imports in the default script.py.mako are now at the top
  so that flake8 editors don't complain by default. PR courtesy
  Guilherme Mansur.

• [feature] [operations] [postgresql] Added support for the USING clause to the ALTER COLUMN operation
  for Postgresql. Support is via the
  op.alter_column.postgresql_using
  parameter. Pull request courtesy Frazer McLean.

  References: #292

• [autogenerate] [feature] Autogenerate with type comparison enabled will pick up on the timezone
  setting changing between DateTime types. Pull request courtesy
  David Szotten.

0.8.7

0.8.7

Released: July 26, 2016

• [bug] [versioning] 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.

  References: #336

• [bug] [versioning] 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 #377
  and #378 to improve treatment of branches with dependencies
  overall.

  References: #379

• [bug] [versioning] 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.

  References: #377

• [bug] [versioning] 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.

  References: #378

• [bug] [versioning] Fixed bug where a repr() or str() of a Script object would fail
  if the script had multiple dependencies.

• [autogenerate] [bug] 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.

• [batch] [bug] 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.

0.8.6

0.8.6

Released: April 14, 2016

• [bug] [commands] 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.

  References: #367

• [bug] [postgresql] 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.

  References: #365

• [batch] [bug] Fixed bug introduced by the fix for #338 in version 0.8.4
  where a server default could no longer be dropped in batch mode.
  Pull request courtesy Martin Domke.

  References: #361

• [batch] [bug] [mssql] Fixed bug where SQL Server arguments for drop_column() would not
  be propagated when running under a batch block. Pull request
  courtesy Michal Petrucha.

0.8.5

0.8.5

Released: March 9, 2016

• [autogenerate] [bug] 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.

  References: #335

• [batch] [bug] 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.

  References: #354

• [bug] [mysql] 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.

  References: #355

0.8.4

0.8.4

Released: December 15, 2015

• [feature] [versioning] 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.

• [autogenerate] [feature] 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.

• [batch] [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.

  References: #345

• [autogenerate] [bug] 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.

  References: #341

• [batch] [bug] Fixed bug where the server_default parameter of alter_column()
  would not function correctly in batch mode.

  References: #338

• [autogenerate] [bug] 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.

  References: #337

0.8.3

0.8.3

Released: October 16, 2015

• [autogenerate] [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.

  References: #332

• [batch] [bug] 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.

  References: #333

• [bug] [tests] 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.

• [autogenerate] [bug] [postgresql] 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.

  References: #324

0.8.2

0.8.2

Released: August 25, 2015

• [autogenerate] [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.

  References: #321

0.8.1

0.8.1

Released: August 22, 2015

• [autogenerate] [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.

• [autogenerate] [bug] Repaired the render operation for the ops.AlterColumnOp object
  to succeed when the "existing_type" field was not present.

• [autogenerate] [bug] 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.

  References: #318

• [autogenerate] [feature] 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).

  References: #317

0.8.0

0.8.0

Released: August 12, 2015

• [batch] [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.

  References: #315

• [commands] [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.

• [commands] [feature] 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.

  References: #311

• [change] [operations] 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()`
  

• [feature] [tests] The default test runner via "python setup.py test" is now py.test.
  nose still works via run_tests.py.

• [feature] [operations] 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.

  References: #302

• [autogenerate] [feature] 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.

  References: #301, #306

• [bug] [versioning] 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.

  References: #314

0.7.7

0.7.7

Released: July 22, 2015

• [bug] [versioning] 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.

  References: #310

• [batch] [feature] 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.

  References: #305

• [bug] [environment] 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.

  References: #300

• [autogenerate] [bug] 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.

  References: #298

• [bug] [tests] Repaired warnings that occur when running unit tests against
  SQLAlchemy 1.0.5 or greater involving the "legacy_schema_aliasing"
  flag.