Releases: sqlalchemy/alembic
0.8.8
0.8.8
Released: September 12, 2016
-
[autogenerate] The imports in the default script.py.mako are now at the top
so that flake8 editors don't complain by default. PR courtesy
Guilherme Mansur. -
[feature] [operations] [postgresql] Added support for the USING clause to the ALTER COLUMN operation
for Postgresql. Support is via the
op.alter_column.postgresql_using
parameter. Pull request courtesy Frazer McLean.References: #292
-
[autogenerate] [feature] Autogenerate with type comparison enabled will pick up on the timezone
setting changing between DateTime types. Pull request courtesy
David Szotten.
0.8.7
0.8.7
Released: July 26, 2016
-
[bug] [versioning] Fixed bug where upgrading to the head of a branch which is already
present would fail, only if that head were also the dependency
of a different branch that is also upgraded, as the revision system
would see this as trying to go in the wrong direction. The check
here has been refined to distinguish between same-branch revisions
out of order vs. movement along sibling branches.References: #336
-
[bug] [versioning] Adjusted the version traversal on downgrade
such that we can downgrade to a version that is a dependency for
a version in a different branch, without needing to remove that
dependent version as well. Previously, the target version would be
seen as a "merge point" for it's normal up-revision as well as the
dependency. This integrates with the changes for #377
and #378 to improve treatment of branches with dependencies
overall.References: #379
-
[bug] [versioning] Fixed bug where a downgrade to a version that is also a dependency
to a different branch would fail, as the system attempted to treat
this as an "unmerge" of a merge point, when in fact it doesn't have
the other side of the merge point available for update.References: #377
-
[bug] [versioning] Fixed bug where the "alembic current" command wouldn't show a revision
as a current head if it were also a dependency of a version in a
different branch that's also applied. Extra logic is added to
extract "implied" versions of different branches from the top-level
versions listed in the alembic_version table.References: #378
-
[bug] [versioning] Fixed bug where a repr() or str() of a Script object would fail
if the script had multiple dependencies. -
[autogenerate] [bug] Fixed bug in autogen where if the DB connection sends the default
schema as "None", this "None" would be removed from the list of
schemas to check if include_schemas were set. This could possibly
impact using include_schemas with SQLite. -
[batch] [bug] Small adjustment made to the batch handling for reflected CHECK
constraints to accommodate for SQLAlchemy 1.1 now reflecting these.
Batch mode still does not support CHECK constraints from the reflected
table as these can't be easily differentiated from the ones created
by types such as Boolean.
0.8.6
0.8.6
Released: April 14, 2016
-
[bug] [commands] Errors which occur within the Mako render step are now intercepted
and raised as CommandErrors like other failure cases; the Mako
exception itself is written using template-line formatting to
a temporary file which is named in the exception message.References: #367
-
[bug] [postgresql] Added a fix to Postgresql server default comparison which first checks
if the text of the default is identical to the original, before attempting
to actually run the default. This accomodates for default-generation
functions that generate a new value each time such as a uuid function.References: #365
-
[batch] [bug] Fixed bug introduced by the fix for #338 in version 0.8.4
where a server default could no longer be dropped in batch mode.
Pull request courtesy Martin Domke.References: #361
-
[batch] [bug] [mssql] Fixed bug where SQL Server arguments for drop_column() would not
be propagated when running under a batch block. Pull request
courtesy Michal Petrucha.
0.8.5
0.8.5
Released: March 9, 2016
-
[autogenerate] [bug] Fixed bug where the columns rendered in a
PrimaryKeyConstraint
in autogenerate would inappropriately render the "key" of the
column, not the name. Pull request courtesy Jesse Dhillon.References: #335
-
[batch] [bug] Repaired batch migration support for "schema" types which generate
constraints, in particular theBoolean
datatype which generates
a CHECK constraint. Previously, an alter column operation with this
type would fail to correctly accommodate for the CHECK constraint
on change both from and to this type. In the former case the operation
would fail entirely, in the latter, the CHECK constraint would
not get generated. Both of these issues are repaired.References: #354
-
[bug] [mysql] Changing a schema type such as
Boolean
to a non-schema type would
emit a drop constraint operation which emitsNotImplementedError
for
the MySQL dialect. This drop constraint operation is now skipped when
the constraint originates from a schema type.References: #355
0.8.4
0.8.4
Released: December 15, 2015
-
[feature] [versioning] A major improvement to the hash id generation function, which for some
reason used an awkward arithmetic formula against uuid4() that produced
values that tended to start with the digits 1-4. Replaced with a
simple substring approach which provides an even distribution. Pull
request courtesy Antti Haapala. -
[autogenerate] [feature] Added an autogenerate renderer for the
ExecuteSQLOp
operation
object; only renders if given a plain SQL string, otherwise raises
NotImplementedError. Can be of help with custom autogenerate
sequences that includes straight SQL execution. Pull request courtesy
Jacob Magnusson. -
[batch] [bug] Batch mode generates a FOREIGN KEY constraint that is self-referential
using the ultimate table name, rather than_alembic_batch_temp
.
When the table is renamed from_alembic_batch_temp
back to the
original name, the FK now points to the right name. This
will not work if referential integrity is being enforced (eg. SQLite
"PRAGMA FOREIGN_KEYS=ON") since the original table is dropped and
the new table then renamed to that name, however this is now consistent
with how foreign key constraints on other tables already operate
with batch mode; these don't support batch mode if referential integrity
is enabled in any case.References: #345
-
[autogenerate] [bug] Added a type-level comparator that distinguishes
Integer
,
BigInteger
, andSmallInteger
types and
dialect-specific types; these all have "Integer" affinity so previously
all compared as the same.References: #341
-
[batch] [bug] Fixed bug where the
server_default
parameter ofalter_column()
would not function correctly in batch mode.References: #338
-
[autogenerate] [bug] Adjusted the rendering for index expressions such that a
Column
object present in the sourceIndex
will not be rendered
as table-qualified; e.g. the column name will be rendered alone.
Table-qualified names here were failing on systems such as Postgresql.References: #337
0.8.3
0.8.3
Released: October 16, 2015
-
[autogenerate] [bug] Fixed an 0.8 regression whereby the "imports" dictionary member of
the autogen context was removed; this collection is documented in the
"render custom type" documentation as a place to add new imports.
The member is now known as
AutogenContext.imports
and the documentation is repaired.References: #332
-
[batch] [bug] Fixed bug in batch mode where a table that had pre-existing indexes
would create the same index on the new table with the same name,
which on SQLite produces a naming conflict as index names are in a
global namespace on that backend. Batch mode now defers the production
of both existing and new indexes until after the entire table transfer
operation is complete, which also means those indexes no longer take
effect during the INSERT from SELECT section as well; the indexes
are applied in a single step afterwards.References: #333
-
[bug] [tests] Added "pytest-xdist" as a tox dependency, so that the -n flag
in the test command works if this is not already installed.
Pull request courtesy Julien Danjou. -
[autogenerate] [bug] [postgresql] Fixed issue in PG server default comparison where model-side defaults
configured with Python unicode literals would leak the "u" character
from arepr()
into the SQL used for comparison, creating an invalid
SQL expression, as the server-side comparison feature in PG currently
repurposes the autogenerate Python rendering feature to get a quoted
version of a plain string default.References: #324
0.8.2
0.8.2
Released: August 25, 2015
-
[autogenerate] [bug] Added workaround in new foreign key option detection feature for
MySQL's consideration of the "RESTRICT" option being the default,
for which no value is reported from the database; the MySQL impl now
corrects for when the model reports RESTRICT but the database reports
nothing. A similar rule is in the default FK comparison to accommodate
for the default "NO ACTION" setting being present in the model but not
necessarily reported by the database, or vice versa.References: #321
0.8.1
0.8.1
Released: August 22, 2015
-
[autogenerate] [feature] A custom
EnvironmentContext.configure.process_revision_directives
hook can now generate op directives within theUpgradeOps
andDowngradeOps
containers that will be generated as Python
code even when the--autogenerate
flag is False; provided that
revision_environment=True
, the full render operation will be run
even in "offline" mode. -
[autogenerate] [bug] Repaired the render operation for the
ops.AlterColumnOp
object
to succeed when the "existing_type" field was not present. -
[autogenerate] [bug] Fixed a regression 0.8 whereby the "multidb" environment template
failed to produce independent migration script segments for the
output template. This was due to the reorganization of the script
rendering system for 0.8. To accommodate this change, the
MigrationScript
structure will in the case of multiple
calls toMigrationContext.run_migrations()
produce lists
for theMigrationScript.upgrade_ops
and
MigrationScript.downgrade_ops
attributes; eachUpgradeOps
andDowngradeOps
instance keeps track of its own
upgrade_token
anddowngrade_token
, and each are rendered
individually.References: #318
-
[autogenerate] [feature] Implemented support for autogenerate detection of changes in the
ondelete
,onupdate
,initially
anddeferrable
attributes ofForeignKeyConstraint
objects on
SQLAlchemy backends that support these on reflection
(as of SQLAlchemy 1.0.8 currently Postgresql for all four,
MySQL forondelete
andonupdate
only). A constraint object
that modifies these values will be reported as a "diff" and come out
as a drop/create of the constraint with the modified values.
The fields are ignored for backends which don't reflect these
attributes (as of SQLA 1.0.8 this includes SQLite, Oracle, SQL Server,
others).References: #317
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 asalembic show
, however runs the target script
file within $EDITOR. Makes use of thepython-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, allowingdepends_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 namesconstraint_name
andtable_name
are now used where previously the namename
would be used.
This is in support of the newly modularized and extensible system of
operation objects inalembic.operations.ops
.
An argument translation layer is in place
across thealembic.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 theop.
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. -
[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()
andBatchOperations.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 theop.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.