alembic / CHANGES

- Added year, month, day, hour, minute, second
  variables to file_template.  #59

- Added 'primary' to the list of constraint types
  recognized for MySQL drop_constraint().

- [bug] Fixed issue whereby reflected server defaults
  wouldn't be quoted correctly; uses repr() now.

- [bug] Fixed issue whereby when autogenerate would
  render create_table() on the upgrade side for a
  table that has a Boolean type, an unnecessary
  CheckConstraint() would be generated. #58

- [feature] Implemented SQL rendering for
  CheckConstraint() within autogenerate upgrade,
  including for literal SQL as well as SQL Expression
  Language expressions.

- [bug] Fixed command-line bug introduced by the
  "revision_environment" feature.

NOTE: 0.3.3 was released with a command line bug,
so please skip right to 0.3.4

- [feature] New config argument
  "revision_environment=true", causes to
  be run unconditionally when the "revision" command
  is run, to support templates with
  dependencies on custom "template_args".

- [feature] Added "template_args" option to configure()
  so that an can add additional arguments
  to the template context when running the
  "revision" command.  This requires either --autogenerate
  or the configuration directive "revision_environment=true".

- [bug] Added "type" argument to op.drop_constraint(),
  and implemented full constraint drop support for
  MySQL.  CHECK and undefined raise an error.
  MySQL needs the constraint type
  in order to emit a DROP CONSTRAINT. #44

- [feature] Added version_table argument to
  EnvironmentContext.configure(), allowing for the
  configuration of the version table name. #34

- [feature] Added support for "relative" migration
  identifiers, i.e. "alembic upgrade +2",
  "alembic downgrade -1".  Courtesy
  Atsushi Odagiri for this feature.

- [bug] Fixed bug whereby directories inside of
  the template directories, such as __pycache__
  on Pypy, would mistakenly be interpreted as
  files which are part of the template. #49

- [feature] Basic support for Oracle added,
  courtesy shgoh. #40

- [feature] Added support for UniqueConstraint
  in autogenerate, courtesy Atsushi Odagiri

- [bug] Fixed support of schema-qualified
  ForeignKey target in column alter operations,
  courtesy Alexander Kolov.

- [bug] Fixed bug whereby create_unique_constraint()
  would include in the constraint columns that
  are added to all Table objects using events,
  externally to the generation of the constraint.

- [bug] bulk_insert() fixes:

    1. bulk_insert() operation was
       not working most likely since the 0.2 series
       when used with an engine. #41
    2. Repaired bulk_insert() to complete when
       used against a lower-case-t table and executing
       with only one set of parameters, working
       around SQLAlchemy bug #2461 in this regard.
    3. bulk_insert() uses "inline=True" so that phrases
       like RETURNING and such don't get invoked for
       single-row bulk inserts.
    4. bulk_insert() will check that you're passing
       a list of dictionaries in, raises TypeError
       if not detected.

- [general] The focus of 0.3 is to clean up
  and more fully document the public API of Alembic,
  including better accessors on the MigrationContext
  and ScriptDirectory objects.  Methods that are
  not considered to be public on these objects have
  been underscored, and methods which should be public
  have been cleaned up and documented, including:


- [feature] Added a bit of autogenerate to the
  public API in the form of the function

- [feature] Informative error message when op.XYZ
  directives are invoked at module import time.

- [bug] Fixed inappropriate direct call to
  util.err() and therefore sys.exit()
  when Config failed to locate the
  config file within library usage.

- [bug] Autogenerate will emit CREATE TABLE
  and DROP TABLE directives according to
  foreign key dependency order.

- [bug] implement 'tablename' parameter on
  drop_index() as this is needed by some

- [feature] Added execution_options parameter
  to op.execute(), will call execution_options()
  on the Connection before executing.

  The immediate use case here is to allow
  access to the new no_parameters option
  in SQLAlchemy 0.7.6, which allows
  some DBAPIs (psycopg2, MySQLdb) to allow
  percent signs straight through without
  escaping, thus providing cross-compatible
  operation with DBAPI execution and
  static script generation.

- [bug] won't install argparse if on
  Python 2.7/3.2

- [feature] script_location can be interpreted
  by pkg_resources.resource_filename(), if
  it is a non-absolute URI that contains
  colons.   This scheme is the same
  one used by Pyramid.  [#29]

- [feature] added missing support for
  onupdate/ondelete flags for
  ForeignKeyConstraint, courtesy Giacomo Bagnoli

- [bug] fixed a regression regarding an autogenerate
  error message, as well as various glitches
  in the Pylons sample template.  The Pylons sample
  template requires that you tell it where to
  get the Engine from now.  courtesy
  Marcin Kuzminski [#30]

- [bug] drop_index() ensures a dummy column
  is added when it calls "Index", as SQLAlchemy
  0.7.6 will warn on index with no column names.

- [bug] Fixed the generation of CHECK constraint,
  regression from 0.2.0 [#26]

- [feature] API rearrangement allows everything
  Alembic does to be represented by contextual
  objects, including EnvironmentContext,
  MigrationContext, and Operations.   Other
  libraries and applications can now use
  things like "alembic.op" without relying
  upon global configuration variables.
  The rearrangement was done such that
  existing migrations should be OK,
  as long as they use the pattern
  of "from alembic import context" and
  "from alembic import op", as these
  are now contextual objects, not modules.

- [feature] The naming of revision files can
  now be customized to be some combination
  of "rev id" and "slug", the latter of which
  is based on the revision message.
  By default, the pattern "<rev>_<slug>"
  is used for new files.   New script files
  should include the "revision" variable
  for this to work, which is part of
  the newer scripts.

- [bug] templates call
  connection.close() to better support
  programmatic usage of commands; use
  NullPool in conjunction with create_engine()
  as well so that no connection resources
  remain afterwards.  [#25]

- [bug] fix the config.main() function to honor
  the arguments passed, remove no longer used
  "scripts/alembic" as setuptools creates this
  for us.  [#22]

- [bug] Fixed alteration of column type on
  MSSQL to not include the keyword "TYPE".

- [feature] Can create alembic.config.Config
  with no filename, use set_main_option()
  to add values.  Also added set_section_option()
  which will add sections.  [#23]

- [bug] Clean up file write operations so that
  file handles are closed.

- [feature] PyPy is supported.

- [feature] Python 2.5 is supported, needs

- [bug] Fix autogenerate so that "pass" is
  generated between the two comments
  if no net migrations were present.

- [bug] Fix autogenerate bug that prevented
  correct reflection of a foreign-key
  referenced table in the list of "to remove".

- [bug] Fix bug where create_table() didn't
  handle self-referential foreign key
  correctly [#17]

- [bug] Default prefix for autogenerate
  directives is "op.", matching the
  mako templates. [#18]

- [feature] Add alembic_module_prefix argument
  to configure() to complement
  sqlalchemy_module_prefix. [#18]

- [bug] fix quotes not being rendered in
  ForeignKeConstraint during
  autogenerate [#14]

- Initial release.  Status of features:

- Alembic is used in at least one production
  environment, but should still be considered
  ALPHA LEVEL SOFTWARE as of this release,
  particularly in that many features are expected
  to be missing / unimplemented.   Major API
  changes are not anticipated but for the moment
  nothing should be assumed.

  The author asks that you *please* report all
  issues, missing features, workarounds etc.
  to the bugtracker, at .

- Python 3 is supported and has been tested.

- The "Pylons" and "MultiDB" environment templates
  have not been directly tested - these should be
  considered to be samples to be modified as
  needed.   Multiple database support itself
  is well tested, however.

- Postgresql and MS SQL Server environments
  have been tested for several weeks in a production
  environment.  In particular, some involved workarounds
  were implemented to allow fully-automated dropping
  of default- or constraint-holding columns with
  SQL Server.

- MySQL support has also been implemented to a
  basic degree, including MySQL's awkward style
  of modifying columns being accommodated.

- Other database environments not included among
  those three have *not* been tested, *at all*.  This
  includes Firebird, Oracle, Sybase.   Adding
  support for these backends should be
  straightforward.  Please report all missing/
  incorrect behaviors to the bugtracker! Patches
  are welcome here but are optional - please just
  indicate the exact format expected by the target

- SQLite, as a backend, has almost no support for
  schema alterations to existing databases.  The author
  would strongly recommend that SQLite not be used in
  a migration context - just dump your SQLite database
  into an intermediary format, then dump it back
  into a new schema.  For dev environments, the
  dev installer should be building the whole DB from
  scratch.  Or just use Postgresql, which is a much
  better database for non-trivial schemas.
  Requests for full ALTER support on SQLite should be
  reported to SQLite's bug tracker at,
  as Alembic will not be implementing the
  "rename the table to a temptable then copy the
  data into a new table" workaround.
  Note that Alembic will at some point offer an
  extensible API so that you can implement commands
  like this yourself.

- Well-tested directives include add/drop table, add/drop
  column, including support for SQLAlchemy "schema"
  types which generate additional CHECK
  constraints, i.e. Boolean, Enum.  Other directives not
  included here have *not* been strongly tested
  in production, i.e. rename table, etc.

- Both "online" and "offline" migrations, the latter
  being generated SQL scripts to hand off to a DBA,
  have been strongly production tested against
  Postgresql and SQL Server.

- Modify column type, default status, nullable, is
  functional and tested across PG, MSSQL, MySQL,
  but not yet widely tested in production usage.

- Many migrations are still outright missing, i.e.
  create/add sequences, etc.  As a workaround,
  execute() can be used for those which are missing,
  though posting of tickets for new features/missing
  behaviors is strongly encouraged.

- Autogenerate feature is implemented and has been
  tested, though only a little bit in a production setting.
  In particular, detection of type and server
  default changes are optional and are off by default;
  they can also be customized by a callable.
  Both features work but can have surprises particularly
  the disparity between BIT/TINYINT and boolean,
  which hasn't yet been worked around, as well as
  format changes performed by the database on defaults
  when it reports back.  When enabled, the PG dialect
  will execute the two defaults to be compared to
  see if they are equivalent.  Other backends may
  need to do the same thing.

  The autogenerate feature only generates
  "candidate" commands which must be hand-tailored
  in any case, so is still a useful feature and
  is safe to use.  Please report missing/broken features
  of autogenerate!  This will be a great feature and
  will also improve SQLAlchemy's reflection services.

- Support for non-ASCII table, column and constraint
  names is mostly nonexistent.   This is also a
  straightforward feature add as SQLAlchemy itself
  supports unicode identifiers; Alembic itself will
  likely need fixes to logging, column identification
  by key, etc. for full support here.

- Support for tables in remote schemas,
  i.e. "schemaname.tablename", is very poor.
  Missing "schema" behaviors should be
  reported as tickets, though in the author's
  experience, migrations typically proceed only
  within the default schema.