Hi list -
Alembic 0.8.0 is now available.
This release includes a large series of reorganizations in order to
provide several new extension APIs which dramatically increase the
degree to which Alembic can be extended.
The average Alembic environment should hopefully not notice anything
different as we've strived to maintain full backwards compatibility.
However, both the "operations" and the "autogenerate" features have been
entirely reorganized in order to produce a much more open-ended and
integrated flow between these two systems.
At the base of the new system, everything in Alembic that is an
"operation" is now boiled down into an object, known as a
MigrateOperation. Subclasses of MigrateOperation include the familiar
things like AddColumnOp, CreateForeignKeyOP, and DropTableOp. These
objects do *not* represent the SQL that we emit for these operations;
the implementation of that remains within the alembic.ddl.* packages as
it did before. Instead, they represent the operation as defined in
Alembic as part of the interface. From these MigrateOperation
objects, we now hang a variety of functions onto each object, including
its representation in the "alembic.op.*" space we're all familiar with
as well as in the "batch_op.*" namespace recently introduced; we hang an
"implementation" onto it which includes how it should interact with the
backend "ddl" system; we hang an Autogenerate "render" hook onto it,
which represents how we'll write out its Python code inside of an
autogenerated revision script, we hang an Autogenerate "determine diffs"
hook onto it, which represents how we should compare a database to a
MetaData structure in order to potentially produce this object during
autogenerate, and we even hang things like a "tuple diff" as well as a
"reverse" operation, to convert upgrades into downgrades and vice
versa. Within autogeneration, we now build up a structure of these
MigrateOperation objects fully before rendering them, rather than going
straight from raw "diff" information into a Python render.
With this new system, we haven't necessarily added any new functionality
that wasn't there before, but we've now organized all the things we know
about an "Alembic operation" centered around this object using
now-public APIs to associate operations with each one.
What this means is that you can now:
* create your own Alembic operations freely, which become available as
first-class functions in alembic.op.* like any other
* create your own autogenerate schemes for these operations, including
defining how to do the database compare as well as render the Python
* Modify completely what autogenerate does when it produces a new
migration script; the entire contents of a generated script are
delivered in object form to user-available hooks which can then rewrite
the structure completely. The autogenerate operation can be made to
generate multiple files to different directories and/or branches, or no
files at all. A helper is also provided to make it easy to write short
replacements of specific elements. Common user requests such as
having autogenerate not produce a file if there were no net changes,
converting an "add column" operation into an "add column, nullable=True"
+ "alter column set not null", or supporting alternative migration flows
such as splitting migrations into "expand" and "contract" branches are
now easily scriptable with no need to add new flags and switches to
Alembic itself.
* Create applications that can receive an autogenerate stream and push
it out directly as Alembic operations to a live database or SQL script,
without even generating any revision scripts.
* Create alternative series of implementations for Alembic operations,
such as writing them out to JSON or XML formats or perhaps building up a
live MetaData structure based on them.
The release also includes a few other fixes and features. In
particular, in conjunction with the reorganization of operations, there
is also a renaming of positional arguments in the alembic.op.*
namespace, however a backwards-compatibility translation layer is
included. I came across some environments where positional arguments
were passed with names, such as op.create_foreign_key(name='foo',
source='source', referent='othertable', ...). Those names are now
changed, however if the operation is called from within the
"alembic.op.*" namespace, the old names when passed as keywords will
still be honored, though a warning will be emitted. The one thing that
does *not* work is if an application is programmatically constructing an
alembic.operations.Operations object directly, then calling methods upon
it and passing positional arguments using the old names. The
overwhelming vast majority of applications should not be constructing
Operations objects as this is a little-needed workflow, but those
applications will need to check their use of old names passed explicitly
for positional arguments. The full list of name changes is listed in
the changelog.
Download Alembic 0.8.0 at: https://pypi.python.org/pypi/alembic/
Full changelog, including new features, bugfixes, as well as links to
all Operations methods where positional argument names that have
changed, are at:
http://alembic.readthedocs.org/en/latest/changelog.html#change-0.8.0.
Thanks to everyone in the community who has helped with this release in
the form of patches, pull requests, bug reports, and mailing list
commentary.
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy-alembic" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sqlalchemy-alembic+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
