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

0.6.6

0.6.6

Released: August 7, 2014

• [bug] A file named __init__.py in the versions/ directory is now
  ignored by Alembic when the collection of version files is retrieved.
  Pull request courtesy Michael Floering.

  References: #95

• [bug] Fixed Py3K bug where an attempt would be made to sort None against
  string values when autogenerate would detect tables across multiple
  schemas, including the default schema. Pull request courtesy
  paradoxxxzero.

• [bug] Autogenerate render will render the arguments within a Table construct
  using *[...] when the number of columns/elements is greater than
  255. Pull request courtesy Ryan P. Kelly.

• [bug] Fixed bug where foreign key constraints would fail to render in
  autogenerate when a schema name was present. Pull request courtesy
  Andreas Zeidler.

• [bug] Some deep-in-the-weeds fixes to try to get "server default" comparison
  working better across platforms and expressions, in particular on
  the Postgresql backend, mostly dealing with quoting/not quoting of various
  expressions at the appropriate time and on a per-backend basis.
  Repaired and tested support for such defaults as Postgresql interval
  and array defaults.

  References: #212

• [enhancement] When a run of Alembic command line fails due to CommandError,
  the output now prefixes the string with "FAILED:", and the error
  is also written to the log output using log.error().

  References: #209

• [bug] Liberalized even more the check for MySQL indexes that shouldn't be
  counted in autogenerate as "drops"; this time it's been reported
  that an implicitly created index might be named the same as a composite
  foreign key constraint, and not the actual columns, so we now skip those
  when detected as well.

  References: #208

• [feature] Added a new accessor MigrationContext.config, when used
  in conjunction with a EnvironmentContext and
  Config, this config will be returned. Patch
  courtesy Marc Abramowitz.

0.6.5

0.6.5

Released: May 3, 2014

• [autogenerate] [bug] [mysql] This releases' "autogenerate index detection" bug, when a MySQL table
  includes an Index with the same name as a column, autogenerate reported
  it as an "add" even though its not; this is because we ignore reflected
  indexes of this nature due to MySQL creating them implicitly. Indexes
  that are named the same as a column are now ignored on
  MySQL if we see that the backend is reporting that it already exists;
  this indicates that we can still detect additions of these indexes
  but not drops, as we cannot distinguish a backend index same-named
  as the column as one that is user generated or mysql-generated.

  References: #202

• [environment] [feature] Added new feature EnvironmentContext.configure.transaction_per_migration,
  which when True causes the BEGIN/COMMIT pair to incur for each migration
  individually, rather than for the whole series of migrations. This is
  to assist with some database directives that need to be within individual
  transactions, without the need to disable transactional DDL entirely.

  References: #201

• [autogenerate] [bug] Fixed bug where the include_object() filter would not receive
  the original Column object when evaluating a database-only
  column to be dropped; the object would not include the parent
  Table nor other aspects of the column that are important
  for generating the "downgrade" case where the column is recreated.

  References: #200

• [bug] [environment] Fixed bug where EnvironmentContext.get_x_argument()
  would fail if the Config in use didn't actually
  originate from a command line call.

  References: #195

• [autogenerate] [bug] Fixed another bug regarding naming conventions, continuing
  from #183, where add_index()
  drop_index() directives would not correctly render the f()
  construct when the index contained a convention-driven name.

  References: #194

0.6.4

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.

0.6.3

0.6.3

Released: February 2, 2014

• [bug] Added a workaround for when we call fcntl.ioctl() to get at
  TERMWIDTH; if the function returns zero, as is reported to occur
  in some pseudo-ttys, the message wrapping system is disabled in the
  same way as if ioctl() failed.

  References: #172

• [feature] Added new argument
  EnvironmentContext.configure.user_module_prefix.
  This prefix is applied when autogenerate renders a user-defined type,
  which here is defined as any type that is from a module outside of the
  sqlalchemy. hierarchy. This prefix defaults to None, in
  which case the EnvironmentContext.configure.sqlalchemy_module_prefix
  is used, thus preserving the current behavior.

  References: #171

• [bug] Added support for autogenerate covering the use case where Table
  objects specified in the metadata have an explicit schema attribute
  whose name matches that of the connection's default schema
  (e.g. "public" for Postgresql). Previously, it was assumed that "schema"
  was None when it matched the "default" schema, now the comparison
  adjusts for this.

  References: #170

• [bug] The compare_metadata() public API function now takes into
  account the settings for
  EnvironmentContext.configure.include_object,
  EnvironmentContext.configure.include_symbol,
  and EnvironmentContext.configure.include_schemas, in the
  same way that the --autogenerate command does. Pull
  request courtesy Roman Podoliaka.

• [bug] Calling bulk_insert() with an empty list will not emit any
  commands on the current connection. This was already the case with
  --sql mode, so is now the case with "online" mode.

  References: #168

• [bug] Enabled schema support for index and unique constraint autodetection;
  previously these were non-functional and could in some cases lead to
  attribute errors. Pull request courtesy Dimitris Theodorou.

• [bug] More fixes to index autodetection; indexes created with expressions
  like DESC or functional indexes will no longer cause AttributeError
  exceptions when attempting to compare the columns.

  References: #164

• [feature] The ScriptDirectory system that loads migration files
  from a versions/ directory now supports so-called
  "sourceless" operation, where the .py files are not present
  and instead .pyc or .pyo files are directly present where
  the .py files should be. Note that while Python 3.3 has a
  new system of locating .pyc/.pyo files within a directory
  called __pycache__ (e.g. PEP-3147), PEP-3147 maintains
  support for the "source-less imports" use case, where the
  .pyc/.pyo are in present in the "old" location, e.g. next
  to the .py file; this is the usage that's supported even when
  running Python3.3.

  References: #163