1.5.2

1.5.2

Released: January 20, 2021

bug

• [bug] [regression] [versioning] Fixed regression where new "loop detection" feature introduced in
  #757 produced false positives for revision names that have
  overlapping substrings between revision number and down revision and/or
  dependency, if the downrev/dependency were not in sequence form.

  References: #784

• [bug] [environment] Fixed regression where Alembic would fail to create a transaction properly
  if the sqlalchemy.engine.Connection were a so-called "branched"
  connection, that is, one where the .connect() method had been called to
  create a "sub" connection.

  References: #782

1.5.1

1.5.1

Released: January 19, 2021

bug

• [bug] [commands] [installation] Fixed installation issue where the "templates" directory was not being
  installed, preventing commands like "list_templates" and "init" from
  working.

  References: #780

1.5.0

1.5.0

Released: January 18, 2021

changed

• [changed] [environment] To accommodate SQLAlchemy 1.4 and 2.0, the migration model now no longer
  assumes that the SQLAlchemy Connection will autocommit an individual
  operation. This essentially means that for databases that use
  non-transactional DDL (pysqlite current driver behavior, MySQL), there is
  still a BEGIN/COMMIT block that will surround each individual migration.
  Databases that support transactional DDL should continue to have the
  same flow, either per migration or per-entire run, depending on the
  value of the Environment.configure.transaction_per_migration
  flag.

• [changed] [environment] A CommandError is raised if a sqlalchemy.engine.Engine is
  passed to the MigrationContext.configure() method instead of a
  sqlalchemy.engine.Connection object. Previously, this would be a
  warning only.

• [changed] Alembic 1.5.0 now supports Python 2.7 and Python 3.6 and above, as well
  as SQLAlchemy 1.3.0 and above. Support is removed for Python 3
  versions prior to 3.6 and SQLAlchemy versions prior to the 1.3 series.

  References: #748

feature

• [feature] [autogenerate] Added new hook EnvironmentContext.configure.include_name,
  which complements the
  EnvironmentContext.configure.include_object hook by providing
  a means of preventing objects of a certain name from being autogenerated
  before the SQLAlchemy reflection process takes place, and notably
  includes explicit support for passing each schema name when
  EnvironmentContext.configure.include_schemas is set to True.
  This is most important especially for enviroments that make use of
  EnvironmentContext.configure.include_schemas where schemas are
  actually databases (e.g. MySQL) in order to prevent reflection sweeps of
  the entire server.

  References: #650

• [feature] [versioning] The revision tree is now checked for cycles and loops between revision
  files when the revision environment is loaded up. Scenarios such as a
  revision pointing to itself, or a revision that can reach itself via a
  loop, are handled and will raise the CycleDetected exception when
  the environment is loaded (expressed from the Alembic commandline as a
  failure message and nonzero return code). Previously, these situations were
  silently ignored up front, and the behavior of revision traversal would
  either be silently incorrect, or would produce errors such as
  RangeNotAncestorError. Pull request courtesy Koichiro Den.

  References: #757

bug

• [bug] [operations] Modified the add_column() operation such that the Column object in
  use is shallow copied to a new instance if that Column is already
  attached to a table() or Table. This accommodates for the change
  made in SQLAlchemy issue #5618 which prohibits a Column from being
  associated with multiple table() objects. This resumes support for
  using a Column inside of an Alembic operation that already refers to a
  parent table() or Table as well as allows operation objects just
  autogenerated to work.

  References: #753

• [bug] [autogenerate] Added rendering for the Table.prefixes element to autogenerate so that
  the rendered Python code includes these directives. Pull request courtesy
  Rodrigo Ce Moretto.

  References: #721

• [bug] [batch] Added missing "create comment" feature for columns that are altered in
  batch migrations.

  References: #761

• [bug] [batch] Made an adjustment to the PostgreSQL dialect to allow it to work more
  effectively in batch mode, where a datatype like Boolean or non-native Enum
  that may have embedded rules to generate CHECK constraints will be more
  correctly handled in that these constraints usually will not have been
  generated on the PostgreSQL backend; previously it would inadvertently
  assume they existed unconditionally in a special PG-only "drop constraint"
  step.

  References: #773

usecase

• [usecase] [operations] Added support for rendering of "identity" elements on
  Column objects, supported in SQLAlchemy via
  the Identity element introduced in version 1.4.

  Adding columns with identity is supported on PostgreSQL,
  MSSQL and Oracle. Changing the identity options or removing
  it is supported only on PostgreSQL and Oracle.

  References: #730

• [usecase] [commands] Add __main__.py file to alembic package to support invocation
  with python -m alembic.

removed

• [removed] [autogenerate] The long deprecated
  EnvironmentContext.configure.include_symbol hook is removed.
  The EnvironmentContext.configure.include_object
  and EnvironmentContext.configure.include_name
  hooks both achieve the goals of this hook.

• [removed] [commands] Removed deprecated --head_only option to the alembic current
  command

• [removed] [operations] Removed legacy parameter names from operations, these have been emitting
  warnings since version 0.8. In the case that legacy version files have not
  yet been updated, these can be modified directly in order to maintain
  compatibility:

  -   `Operations.drop_constraint()` - "type" (use "type_") and "name"
      (use "constraint_name")
  
  -   `Operations.create_primary_key()` - "cols" (use "columns") and
      "name" (use "constraint_name")
  
  -   `Operations.create_unique_constraint()` - "name" (use
      "constraint_name"), "source" (use "table_name") and "local_cols" (use
      "columns")
  
  -   `Operations.batch_create_unique_constraint()` - "name" (use
      "constraint_name")
  
  -   `Operations.create_foreign_key()` - "name" (use "constraint_name"),
      "source" (use "source_table"), "referent" (use "referent_table")
  
  -   `Operations.batch_create_foreign_key()` - "name" (use
      "constraint_name"), "referent" (use "referent_table")
  
  -   `Operations.create_check_constraint()` - "name" (use
      "constraint_name"), "source" (use "table_name")
  
  -   `Operations.batch_create_check_constraint()` - "name" (use
      "constraint_name")
  
  -   `Operations.create_index()` - "name" (use "index_name")
  
  -   `Operations.drop_index()` - "name" (use "index_name"), "tablename"
      (use "table_name")
  
  -   `Operations.batch_drop_index()` - "name" (use "index_name"),
  
  -   `Operations.create_table()` - "name" (use "table_name")
  
  -   `Operations.drop_table()` - "name" (use "table_name")
  
  -   `Operations.alter_column()` - "name" (use "new_column_name")
  

1.4.3

1.4.3

Released: September 11, 2020

bug

• [bug] [batch] [sqlite] Added support to drop named CHECK constraints that are specified as part of
  a column, rather than table wide. Previously, only constraints associated
  with the table were considered.

  References: #711

• [bug] [mysql] [ops] Fixed issue where the MySQL dialect would not correctly render the server
  default of a column in an alter operation, if the operation were
  programmatically generated from an autogenerate pass as it would not
  accommodate for the full structure of the DefaultClause construct.

  References: #736

• [bug] [batch] [sqlite] Fixed issue where the CAST applied to a JSON column when copying a SQLite
  table during batch mode would cause the data to be lost, as SQLite's CAST
  with JSON appears to convert the data to the value "0". The CAST is now
  skipped in a dialect-specific manner, including for JSON columns on SQLite.
  Pull request courtesy Sebastián Ramírez.

  References: #697

• [bug] [commands] The alembic current command no longer creates an alembic_version
  table in the database if one does not exist already, returning no version
  as the current version. This allows checking for migrations in parallel
  without introducing race conditions. Pull request courtesy Nikolay
  Edigaryev.

  References: #694

• [bug] [batch] Fixed issue where columns in a foreign-key referenced table would be
  replaced with null-type columns during a batch operation; while this did
  not generally have any side effects, it could theoretically impact a batch
  operation that also targets that table directly and also would interfere
  with future changes to the .append_column() method to disallow implicit
  replacement of columns.

• [bug] [mssql] Fixed issue where the mssql_drop_foreign_key=True flag on
  op.drop_column would lead to incorrect syntax error due to a typo in the
  SQL emitted, same typo was present in the test as well so it was not
  detected. Pull request courtesy Oleg Shigorin.

  References: #716

1.4.2

1.4.2

Released: March 19, 2020

bug

• [bug] [tests] Fixed an issue that prevented the test suite from running with the
  recently released py.test 5.4.0.

  References: #668

• [bug] [autogenerate] [mysql] Fixed more false-positive failures produced by the new "compare type" logic
  first added in #605, particularly impacting MySQL string types
  regarding flags such as "charset" and "collation".

  References: #617

• [bug] [op directives] [oracle] Fixed issue in Oracle backend where a table RENAME with a schema-qualified
  name would include the schema in the "to" portion, which is rejected by
  Oracle.

  References: #670

usecase

• [usecase] [autogenerate] Adjusted autogen comparison to accommodate for backends that support
  computed column reflection, dependent on SQLAlchemy version 1.3.16 or
  higher. This emits a warning if the SQL expression inside of a
  Computed value changes between the metadata and the database, as
  these expressions can't be changed without dropping and recreating the
  column.

  References: #669

1.4.1

1.4.1

Released: March 1, 2020

bug

• [bug] [autogenerate] Fixed regression caused by the new "type comparison" logic introduced in
  1.4 as part of #605 where comparisons of MySQL "unsigned integer"
  datatypes would produce false positives, as the regular expression logic
  was not correctly parsing the "unsigned" token when MySQL's default display
  width would be returned by the database. Pull request courtesy Paul
  Becotte.

  References: #661

• [bug] [environment] Error message for "path doesn't exist" when loading up script environment
  now displays the absolute path. Pull request courtesy Rowan Hart.

  References: #663

• [bug] [autogenerate] Fixed regression in 1.4.0 due to #647 where unique constraint
  comparison with mixed case constraint names while not using a naming
  convention would produce false positives during autogenerate.

  References: #654

• [bug] [environment] The check for matched rowcount when the alembic_version table is updated or
  deleted from is now conditional based on whether or not the dialect
  supports the concept of "rowcount" for UPDATE or DELETE rows matched. Some
  third party dialects do not support this concept. Pull request courtesy Ke
  Zhu.

• [bug] [operations] Fixed long-standing bug where an inline column CHECK constraint would not
  be rendered within an "ADD COLUMN" operation. The DDL compiler is now
  consulted for inline constraints within the Operations.add_column()
  method as is done for regular CREATE TABLE operations.

  References: #655

1.4.0

1.4.0

Released: February 4, 2020

feature

• [feature] [batch] Added new parameters BatchOperations.add_column.insert_before,
  BatchOperations.add_column.insert_after which provide for
  establishing the specific position in which a new column should be placed.
  Also added Operations.batch_alter_table.partial_reordering
  which allows the complete set of columns to be reordered when the new table
  is created. Both operations apply only to when batch mode is recreating
  the whole table using recreate="always". Thanks to Marcin Szymanski
  for assistance with the implementation.

  References: #640

bug

• [bug] [autogenerate] Adjusted the unique constraint comparison logic in a similar manner as that
  of #421 did for indexes in order to take into account SQLAlchemy's
  own truncation of long constraint names when a naming convention is in use.
  Without this step, a name that is truncated by SQLAlchemy based on a unique
  constraint naming convention or hardcoded name will not compare properly.

  References: #647

• [bug] [autogenerate] A major rework of the "type comparison" logic is in place which changes the
  entire approach by which column datatypes are compared. Types are now
  compared based on the DDL string generated by the metadata type vs. the
  datatype reflected from the database. This means we compare types based on
  what would actually render and additionally if elements of the types change
  like string length, those changes are detected as well. False positives
  like those generated between SQLAlchemy Boolean and MySQL TINYINT should
  also be resolved. Thanks very much to Paul Becotte for lots of hard work
  and patience on this one.

  References: #605

usecase

• [usecase] [environment] Moved the use of the __file__ attribute at the base of the Alembic
  package into the one place that it is specifically needed, which is when
  the config attempts to locate the template directory. This helps to allow
  Alembic to be fully importable in environments that are using Python
  memory-only import schemes. Pull request courtesy layday.

  References: #648

misc

• [change] The internal inspection routines no longer use SQLAlchemy's
  Inspector.from_engine() method, which is expected to be deprecated in
  1.4. The inspect() function is now used.

1.3.3

1.3.3

Released: January 22, 2020

bug

• [bug] [postgresql] Fixed issue where COMMENT directives for PostgreSQL failed to correctly
  include an explicit schema name, as well as correct quoting rules for
  schema, table, and column names. Pull request courtesy Matthew Sills.

  References: #637

usecase

• [usecase] [operations] Added support for rendering of "computed" elements on Column
  objects, supported in SQLAlchemy via the new Computed element
  introduced in version 1.3.11. Pull request courtesy Federico Caselli.

  Note that there is currently no support for ALTER COLUMN to add, remove, or
  modify the "GENERATED ALWAYS AS" element from a column; at least for
  PostgreSQL, it does not seem to be supported by the database. Additionally,
  SQLAlchemy does not currently reliably reflect the "GENERATED ALWAYS AS"
  phrase from an existing column, so there is also no autogenerate support
  for addition or removal of the Computed element to or from an
  existing column, there is only support for adding new columns that include
  the Computed element. In the case that the Computed
  element is removed from the Column object in the table metadata,
  PostgreSQL and Oracle currently reflect the "GENERATED ALWAYS AS"
  expression as the "server default" which will produce an op that tries to
  drop the element as a default.

  References: #624

1.3.2

1.3.2

Released: December 16, 2019

bug

• [bug] [api] [autogenerate] Fixed regression introduced by #579 where server default rendering
  functions began to require a dialect implementation, however the
  render_python_code() convenience function did not include one, thus
  causing the function to fail when used in a server default context. The
  function now accepts a migration context argument and also creates one
  against the default dialect if one is not provided.

  References: #635

1.3.1

1.3.1

no release date

bug

• [bug] [mssql] Fixed bug in MSSQL dialect where the drop constraint execution steps used
  to remove server default or implicit foreign key constraint failed to take
  into account the schema name of the target table.

  References: #621