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