1.9.1

1.9.1

Released: December 23, 2022

bug

• [bug] [autogenerate] Fixed issue where server default compare would not work for string defaults
  that contained backslashes, due to mis-rendering of these values when
  comparing their contents.

  References: #1145

• [bug] [oracle] Implemented basic server default comparison for the Oracle backend;
  previously, Oracle's formatting of reflected defaults prevented any
  matches from occurring.

• [bug] [sqlite] Adjusted SQLite's compare server default implementation to better handle
  defaults with or without parens around them, from both the reflected and
  the local metadata side.

• [bug] [mssql] Adjusted SQL Server's compare server default implementation to better
  handle defaults with or without parens around them, from both the reflected
  and the local metadata side.

1.9.0

1.9.0

Released: December 15, 2022

feature

• [feature] [commands] Added new Alembic command alembic check. This performs the widely
  requested feature of running an "autogenerate" comparison between the
  current database and the MetaData that's currently set up for
  autogenerate, returning an error code if the two do not match, based on
  current autogenerate settings. Pull request courtesy Nathan Louie.

  References: #724

bug

• [bug] [tests] Fixed issue in tox.ini file where changes in the tox 4.0 series to the
  format of "passenv" caused tox to not function correctly, in particular
  raising an error as of tox 4.0.6.

• [bug] [typing] Fixed typing issue where revision.process_revision_directives
  was not fully typed; additionally ensured all Callable and Dict
  arguments to EnvironmentContext.configure() include parameters in
  the typing declaration.

  Additionally updated the codebase for Mypy 0.990 compliance.

  References: #1110

1.8.1

1.8.1

Released: July 13, 2022

bug

• [bug] [sqlite] Fixed bug where the SQLite implementation of
  Operations.rename_table() would render an explicit schema name for
  both the old and new table name, which while is the standard ALTER syntax,
  is not accepted by SQLite's syntax which doesn't support a rename across
  schemas. In particular, the syntax issue would prevent batch mode from
  working for SQLite databases that made use of attached databases (which are
  treated as "schemas" in SQLAlchemy).

  References: #1065

• [bug] [batch] Added an error raise for the condition where
  Operations.batch_alter_table() is used in --sql mode, where the
  operation requires table reflection, as is the case when running against
  SQLite without giving it a fixed Table object. Previously the operation
  would fail with an internal error. To get a "move and copy" batch
  operation as a SQL script without connecting to a database,
  a Table object should be passed to the
  Operations.batch_alter_table.copy_from parameter so that
  reflection may be skipped.

  References: #1021

1.8.0

1.8.0

Released: May 31, 2022

changed

• [changed] [installation] Alembic 1.8 now supports Python 3.7 and above.

  References: #1025

• [changed] [environment] The "Pylons" environment template has been removed as of Alembic 1.8. This
  template was based on the very old pre-Pyramid Pylons web framework which
  has been long superseded by Pyramid.

  References: #987

feature

• [feature] [typing] PEP 484 typing annotations have been added to the env.py and
  revision template files within migration templates. Pull request by Nikita
  Sobolev.

  References: #764

usecase

• [usecase] [operations] The op.drop_table() operation directive will now trigger the
  before_drop() and after_drop() DDL event hooks at the table level,
  which is similar to how the before_create() and after_create()
  hooks are triggered by the op.create_table() directive. Note that as
  op.drop_table() accepts only a table name and optional schema name, the
  Table object received by the event will not have any information within
  it other than the table name and schema name.

  References: #1037

• [usecase] [commands] Added new token epoch to the file_template option, which will
  populate the integer epoch as determined by int(create_date.timestamp()).
  Pull request courtesy Caio Carvalho.

  References: #1027

bug

• [bug] [revisioning] Fixed issue where a downgrade using a relative revision would
  fail in case of multiple branches with a single effectively
  head due to interdependencies between revisions.

  References: #1026

• [bug] [batch] Fixed issue in batch mode where CREATE INDEX would not use a new column
  name in the case of a column rename.

  References: #1034

1.7.7

1.7.7

Released: March 14, 2022

bug

• [bug] [operations] Fixed issue where using Operations.create_table() in conjunction
  with a CheckConstraint that referred to table-bound
  Column objects rather than string expressions would be added to
  the parent table potentially multiple times, resulting in an incorrect DDL
  sequence. Pull request courtesy Nicolas CANIART.

  References: #1004

• [bug] [environment] The logging.fileConfig() line in env.py templates, which is used
  to setup Python logging for the migration run, is now conditional on
  Config.config_file_name not being None. Otherwise, the line
  is skipped as there is no default logging configuration present.

  References: #986

• [bug] [mssql] Fixed bug where an Operations.alter_column() operation would change
  a "NOT NULL" column to "NULL" by emitting an ALTER COLUMN statement that
  did not specify "NOT NULL". (In the absence of "NOT NULL" T-SQL was
  implicitly assuming "NULL"). An Operations.alter_column() operation
  that specifies Operations.alter_column.type should also
  specify include either Operations.alter_column.nullable or
  Operations.alter_column.existing_nullable to inform Alembic as
  to whether the emitted DDL should include "NULL" or "NOT NULL"; a warning
  is now emitted if this is missing under this scenario.

  References: #977

1.7.6

1.7.6

Released: February 1, 2022

usecase

• [usecase] [commands] Add a new command alembic ensure_version, which will ensure that the
  Alembic version table is present in the target database, but does not
  alter its contents. Pull request courtesy Kai Mueller.

  References: #964

bug

• [bug] [batch] [regression] Fixed regression where usage of a with_variant() datatype in
  conjunction with the existing_type option of op.alter_column()
  under batch mode would lead to an internal exception.

  References: #982

• [bug] [autogenerate] Implemented support for recognizing and rendering SQLAlchemy "variant"
  types going forward into SQLAlchemy 2.0, where the architecture of
  "variant" datatypes will be changing.

• [bug] [autogenerate] [mysql] Added a rule to the MySQL impl so that the translation between JSON /
  LONGTEXT is accommodated by autogenerate, treating LONGTEXT from the server
  as equivalent to an existing JSON in the model.

  References: #968

misc

• [mssql] Removed a warning raised by SQLAlchemy when dropping constraints
  on MSSQL regarding statement caching.

1.7.5

1.7.5

Released: November 11, 2021

bug

• [bug] [tests] Adjustments to the test suite to accommodate for error message changes
  occurring as of SQLAlchemy 1.4.27.

1.7.4

1.7.4

Released: October 6, 2021

bug

• [bug] [regression] Fixed a regression that prevented the use of post write hooks
  on python version lower than 3.9

  References: #934

• [bug] [environment] Fixed issue where the MigrationContext.autocommit_block() feature
  would fail to function when using a SQLAlchemy engine using 2.0 future
  mode.

  References: #944

1.7.3

1.7.3

Released: September 17, 2021

bug

• [bug] [mypy] Fixed type annotations for the "constraint_name" argument of operations
  create_primary_key(), create_foreign_key(). Pull request courtesy
  TilmanK.

  References: #914

1.7.2

1.7.2

Released: September 17, 2021

bug

• [bug] [typing] Added missing attributes from context stubs.

  References: #900

• [bug] [mypy] Fixed an import in one of the .pyi files that was triggering an
  assertion error in some versions of mypy.

  References: #897

• [bug] [ops] [regression] Fixed issue where registration of custom ops was prone to failure due to
  the registration process running exec() on generated code that as of
  the 1.7 series includes pep-484 annotations, which in the case of end user
  code would result in name resolution errors when the exec occurs. The logic
  in question has been altered so that the annotations are rendered as
  forward references so that the exec() can proceed.

  References: #920