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

0.7.4

0.7.4

Released: January 12, 2015

• [autogenerate] [bug] [postgresql] Repaired issue where a server default specified without text()
  that represented a numeric or floating point (e.g. with decimal places)
  value would fail in the Postgresql-specific check for "compare server
  default"; as PG accepts the value with quotes in the table specification,
  it's still valid. Pull request courtesy Dimitris Theodorou.

  References: #241

• [autogenerate] [bug] The rendering of a ~sqlalchemy.schema.ForeignKeyConstraint
  will now ensure that the names of the source and target columns are
  the database-side name of each column, and not the value of the
  .key attribute as may be set only on the Python side.
  This is because Alembic generates the DDL for constraints
  as standalone objects without the need to actually refer to an in-Python
  ~sqlalchemy.schema.Table object, so there's no step that
  would resolve these Python-only key names to database column names.

  References: #259

• [autogenerate] [bug] Fixed bug in foreign key autogenerate where if the in-Python table
  used custom column keys (e.g. using the key='foo' kwarg to
  Column), the comparison of existing foreign keys to those specified
  in the metadata would fail, as the reflected table would not have
  these keys available which to match up. Foreign key comparison for
  autogenerate now ensures it's looking at the database-side names
  of the columns in all cases; this matches the same functionality
  within unique constraints and indexes.

  References: #260

• [autogenerate] [bug] Fixed issue in autogenerate type rendering where types that belong
  to modules that have the name "sqlalchemy" in them would be mistaken
  as being part of the sqlalchemy. namespace. Pull req courtesy
  Bartosz Burclaf.

  References: #261

0.7.3

0.7.3

Released: December 30, 2014

• [bug] [versioning] Fixed regression in new versioning system where upgrade / history
  operation would fail on AttributeError if no version files were
  present at all.

  References: #258

0.7.2

0.7.2

Released: December 18, 2014

• [autogenerate] [bug] [sqlite] Adjusted the SQLite backend regarding autogen of unique constraints
  to work fully with the current SQLAlchemy 1.0, which now will report
  on UNIQUE constraints that have no name.

• [batch] [bug] Fixed bug in batch where if the target table contained multiple
  foreign keys to the same target table, the batch mechanics would
  fail with a "table already exists" error. Thanks for the help
  on this from Lucas Kahlert.

  References: #254

• [bug] [mysql] Fixed an issue where the MySQL routine to skip foreign-key-implicit
  indexes would also catch unnamed unique indexes, as they would be
  named after the column and look like the FK indexes. Pull request
  courtesy Johannes Erdfelt.

  References: #251

• [bug] [mssql] [oracle] Repaired a regression in both the MSSQL and Oracle dialects whereby
  the overridden _exec() method failed to return a value, as is
  needed now in the 0.7 series.

  References: #253

0.7.1

0.7.1

Released: December 3, 2014

• [batch] [bug] The render_as_batch flag was inadvertently hardcoded to True,
  so all autogenerates were spitting out batch mode...this has been
  fixed so that batch mode again is only when selected in env.py.

• [autogenerate] [feature] Support for autogenerate of FOREIGN KEY constraints has been added.
  These are delivered within the autogenerate process in the same
  manner as UNIQUE constraints, including include_object support.
  Big thanks to Ann Kamyshnikova for doing the heavy lifting here.

  References: #178

• [batch] [feature] Added ~.Operations.batch_alter_table.naming_convention
  argument to Operations.batch_alter_table(), as this is necessary
  in order to drop foreign key constraints; these are often unnamed
  on the target database, and in the case that they are named, SQLAlchemy
  is as of the 0.9 series not including these names yet.

• [batch] [bug] Fixed bug where the "source_schema" argument was not correctly passed
  when calling BatchOperations.create_foreign_key(). Pull
  request courtesy Malte Marquarding.

• [batch] [bug] Repaired the inspection, copying and rendering of CHECK constraints
  and so-called "schema" types such as Boolean, Enum within the batch
  copy system; the CHECK constraint will not be "doubled" when the table is
  copied, and additionally the inspection of the CHECK constraint for
  its member columns will no longer fail with an attribute error.

  References: #249

• [batch] [feature] Added two new arguments
  Operations.batch_alter_table.reflect_args
  and Operations.batch_alter_table.reflect_kwargs, so that
  arguments may be passed directly to suit the
  ~.sqlalchemy.schema.Table
  object that will be reflected.

0.7.0

0.7.0

Released: November 24, 2014

• [feature] [versioning] The "multiple heads / branches" feature has now landed. This is
  by far the most significant change Alembic has seen since its inception;
  while the workflow of most commands hasn't changed, and the format
  of version files and the alembic_version table are unchanged as well,
  a new suite of features opens up in the case where multiple version
  files refer to the same parent, or to the "base". Merging of
  branches, operating across distinct named heads, and multiple
  independent bases are now all supported. The feature incurs radical
  changes to the internals of versioning and traversal, and should be
  treated as "beta mode" for the next several subsequent releases
  within 0.7.

  References: #167

• [feature] [versioning] In conjunction with support for multiple independent bases, the
  specific version directories are now also configurable to include
  multiple, user-defined directories. When multiple directories exist,
  the creation of a revision file with no down revision requires
  that the starting directory is indicated; the creation of subsequent
  revisions along that lineage will then automatically use that
  directory for new files.

  References: #124

• [feature] [operations] [sqlite] Added "move and copy" workflow, where a table to be altered is copied to
  a new one with the new structure and the old one dropped, is now
  implemented for SQLite as well as all database backends in general
  using the new Operations.batch_alter_table() system. This
  directive provides a table-specific operations context which gathers
  column- and constraint-level mutations specific to that table, and
  at the end of the context creates a new table combining the structure
  of the old one with the given changes, copies data from old table to new,
  and finally drops the old table,
  renaming the new one to the existing name. This is required for
  fully featured SQLite migrations, as SQLite has very little support for the
  traditional ALTER directive. The batch directive
  is intended to produce code that is still compatible with other databases,
  in that the "move and copy" process only occurs for SQLite by default,
  while still providing some level of sanity to SQLite's
  requirement by allowing multiple table mutation operations to
  proceed within one "move and copy" as well as providing explicit
  control over when this operation actually occurs. The "move and copy"
  feature may be optionally applied to other backends as well, however
  dealing with referential integrity constraints from other tables must
  still be handled explicitly.

  References: #21

• [commands] [feature] Relative revision identifiers as used with alembic upgrade,
  alembic downgrade and alembic history can be combined with
  specific revisions as well, e.g. alembic upgrade ae10+3, to produce
  a migration target relative to the given exact version.

• [bug] [commands] The alembic revision command accepts the --sql option to
  suit some very obscure use case where the revision_environment
  flag is set up, so that env.py is run when alembic revision
  is run even though autogenerate isn't specified. As this flag is
  otherwise confusing, error messages are now raised if
  alembic revision is invoked with both --sql and
  --autogenerate or with --sql without
  revision_environment being set.

  References: #248

• [autogenerate] [bug] [postgresql] Added a rule for Postgresql to not render a "drop unique" and "drop index"
  given the same name; for now it is assumed that the "index" is the
  implicit one Postgreql generates. Future integration with
  new SQLAlchemy 1.0 features will improve this to be more
  resilient.

  References: #247

• [autogenerate] [bug] A change in the ordering when columns and constraints are dropped;
  autogenerate will now place the "drop constraint" calls before
  the "drop column" calls, so that columns involved in those constraints
  still exist when the constraint is dropped.

  References: #247

• [commands] [feature] New commands added: alembic show, alembic heads and
  alembic merge. Also, a new option --verbose has been
  added to several informational commands, such as alembic history,
  alembic current, alembic branches, and alembic heads.
  alembic revision also contains several new options used
  within the new branch management system. The output of commands has
  been altered in many cases to support new fields and attributes;
  the history command in particular now returns it's "verbose" output
  only if --verbose is sent; without this flag it reverts to it's
  older behavior of short line items (which was never changed in the docs).

• [changed] [commands] The --head_only option to the alembic current command is
  deprecated; the current command now lists just the version numbers
  alone by default; use --verbose to get at additional output.

• [config] [feature] Added new argument Config.config_args, allows a dictionary
  of replacement variables to be passed which will serve as substitution
  values when an API-produced Config consumes the .ini
  file. Pull request courtesy Noufal Ibrahim.

• [bug] [oracle] The Oracle dialect sets "transactional DDL" to False by default,
  as Oracle does not support transactional DDL.

  References: #245

• [autogenerate] [bug] Fixed a variety of issues surrounding rendering of Python code that
  contains unicode literals. The first is that the "quoted_name" construct
  that SQLAlchemy uses to represent table and column names as well
  as schema names does not repr() correctly on Py2K when the value
  contains unicode characters; therefore an explicit stringification is
  added to these. Additionally, SQL expressions such as server defaults
  were not being generated in a unicode-safe fashion leading to decode
  errors if server defaults contained non-ascii characters.

  References: #243

• [bug] [operations] The Operations.add_column() directive will now additionally emit
  the appropriate CREATE INDEX statement if the
  ~sqlalchemy.schema.Column object specifies index=True.
  Pull request courtesy David Szotten.

  References: #174

• [feature] [operations] The ~sqlalchemy.schema.Table object is now returned when
  the Operations.create_table() method is used. This Table
  is suitable for use in subsequent SQL operations, in particular
  the Operations.bulk_insert() operation.

  References: #205

• [autogenerate] [feature] Indexes and unique constraints are now included in the
  EnvironmentContext.configure.include_object hook.
  Indexes are sent with type "index" and unique constraints with
  type "unique_constraint".

  References: #203

• [autogenerate] [bug] Bound parameters are now resolved as "literal" values within the
  SQL expression inside of a CheckConstraint(), when rendering the SQL
  as a text string; supported for SQLAlchemy 0.8.0 and forward.

  References: #219

• [autogenerate] [bug] Added a workaround for SQLAlchemy issue #3023 (fixed in 0.9.5) where
  a column that's part of an explicit PrimaryKeyConstraint would not
  have its "nullable" flag set to False, thus producing a false
  autogenerate. Also added a related correction to MySQL which will
  correct for MySQL's implicit server default of '0' when a NULL integer
  column is turned into a primary key column.

  References: #199

• [autogenerate] [bug] [mysql] Repaired issue related to the fix for #208 and others; a composite
  foreign key reported by MySQL would cause a KeyError as Alembic
  attempted to remove MySQL's implicitly generated indexes from the
  autogenerate list.

  References: #240

• [autogenerate] [bug] If the "alembic_version" table is present in the target metadata,
  autogenerate will skip this also. Pull request courtesy
  Dj Gilcrease.

  References: #28

• [autogenerate] [bug] The EnvironmentContext.configure.version_table
  and EnvironmentContext.configure.version_table_schema
  arguments are now honored during the autogenerate process, such that
  these names will be used as the "skip" names on both the database
  reflection and target metadata sides.

  References: #77

• [autogenerate] [changed] The default value of the
  EnvironmentContext.configure.user_module_prefix
  parameter is no longer the same as the SQLAlchemy prefix.
  When omitted, user-defined types will now use the __module__
  attribute of the type class itself when rendering in an
  autogenerated module.

  References: #229

• [bug] [templates] Revision files are now written out using the 'wb' modifier to
  open(), since Mako reads the templates with 'rb', thus preventing
  CRs from being doubled up as has been observed on windows. The encoding
  of the output now defaults to 'utf-8', which can be configured using
  a newly added config file parameter output_encoding.

  References: #234

• [bug] [operations] Added support for use of the ~sqlalchemy.sql.elements.quoted_name
  construct when using the schema argument within operations. This
  allows a name containing a dot to be fully quoted, as well as to
  provide configurable quoting on a per-name basis.
  ...

0.6.7

0.6.7

Released: September 9, 2014

• [bug] [mssql] Fixed bug in MSSQL dialect where "rename table" wasn't using
  sp_rename() as is required on SQL Server. Pull request courtesy
  Łukasz Bołdys.

• [feature] Added support for functional indexes when using the
  Operations.create_index() directive. Within the list of columns,
  the SQLAlchemy text() construct can be sent, embedding a literal
  SQL expression; the Operations.create_index() will perform some hackery
  behind the scenes to get the Index construct to cooperate.
  This works around some current limitations in Index
  which should be resolved on the SQLAlchemy side at some point.

  References: #222