- [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] setup.py won't install argparse if on
- [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 script.py.mako scripts.
- [bug] env.py 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
- [bug] Default prefix for autogenerate
directives is "op.", matching the
mako templates. [#18]
- [feature] Add alembic_module_prefix argument
to configure() to complement
- [bug] fix quotes not being rendered in
- 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
- 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.