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.

0.7.6

0.7.6

Released: May 5, 2015

• [feature] [versioning] 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. Merge points were
  previously assumed to always require at least an UPDATE in
  alembic_revision from one of the previous revs to the new one,
  however in this case, if one of the mergepoints has already
  been reached, the remaining mergepoints have no row to UPDATE therefore
  they must do an INSERT of their target version.

  References: #297

• [autogenerate] [feature] 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.
  Added a new documentation section compare_types describing
  type comparison fully.

  References: #296

• [feature] [operations] Added a new option
  EnvironmentContext.configure.literal_binds, which
  will pass the literal_binds flag into the compilation of SQL
  constructs when using "offline" mode. This has the effect that
  SQL objects like inserts, updates, deletes as well as textual
  statements sent using text() will be compiled such that the dialect
  will attempt to render literal values "inline" automatically.
  Only a subset of types is typically supported; the
  Operations.inline_literal() construct remains as the construct
  used to force a specific literal representation of a value.
  The EnvironmentContext.configure.literal_binds flag
  is added to the "offline" section of the env.py files generated
  in new environments.

  References: #255

• [batch] [bug] Fully implemented the
  ~.Operations.batch_alter_table.copy_from parameter for
  batch mode, which previously was not functioning. This allows
  "batch mode" to be usable in conjunction with --sql.

  References: #289

• [batch] [bug] Repaired support for the BatchOperations.create_index()
  directive, which was mis-named internally such that the operation
  within a batch context could not proceed. The create index
  operation will proceed as part of a larger "batch table recreate"
  operation only if
  ~.Operations.batch_alter_table.recreate is set to
  "always", or if the batch operation includes other instructions that
  require a table recreate.

  References: #287

0.7.5

0.7.5

Released: March 19, 2015

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

  References: #266

• [bug] [mssql] [operations] Fixed bug where the mssql DROP COLUMN directive failed to include
  modifiers such as "schema" when emitting the DDL.

  References: #284

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

  References: #282

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

  References: #276

• [bug] [commands] Fixed bug where using a partial revision identifier as the
  "starting revision" in --sql mode in a downgrade operation
  would fail to resolve properly.

  As a side effect of this change, the
  EnvironmentContext.get_starting_revision_argument()
  method will return the "starting" revision in its originally-
  given "partial" form in all cases, whereas previously when
  running within the command.stamp() command, it would have
  been resolved to a full number before passing it to the
  EnvironmentContext. The resolution of this value to
  a real revision number has basically been moved to a more fundamental
  level within the offline migration process.

  References: #269

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

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

• [feature] [versioning] Added support for "alembic stamp" to work when given "heads" as an
  argument, when multiple heads are present.

  References: #267