1.5.5

1.5.5

Released: February 20, 2021

bug

• [bug] Adjusted the use of SQLAlchemy's ".copy()" internals to use "._copy()"
  for version 1.4.0, as this method is being renamed.

• [bug] [environment] Added new config file option prepend_sys_path, which is a series of
  paths that will be prepended to sys.path; the default value in newly
  generated alembic.ini files is ".". This fixes a long-standing issue
  where for some reason running the alembic command line would not place the
  local "." path in sys.path, meaning an application locally present in "."
  and importable through normal channels, e.g. python interpreter, pytest,
  etc. would not be located by Alembic, even though the env.py file is
  loaded relative to the current path when alembic.ini contains a
  relative path. To enable for existing installations, add the option to the
  alembic.ini file as follows:

  sys.path path, will be prepended to sys.path if present.

  defaults to the current working directory.

  prepend_sys_path = .References: #797

1.5.4

1.5.4

Released: February 3, 2021

bug

• [bug] [versioning] Fixed bug in versioning model where a downgrade across a revision with a
  dependency on another branch, yet an ancestor is also dependent on that
  branch, would produce an erroneous state in the alembic_version table,
  making upgrades impossible without manually repairing the table.

  References: #789

1.5.3

1.5.3

Released: January 29, 2021

bug

• [bug] [autogenerate] Changed the default ordering of "CREATE" and "DROP" statements indexes and
  unique constraints within the autogenerate process, so that for example in
  an upgrade() operation, a particular index or constraint that is to be
  replaced such as for a casing convention change will not produce any naming
  conflicts. For foreign key constraint objects, this is already how
  constraints are ordered, and for table objects, users would normally want
  to use Operations.rename_table() in any case.

  References: #786

• [bug] [autogenerate] [mssql] Fixed assorted autogenerate issues with SQL Server:

  -   ignore default reflected identity on primary_key columns
  
  -   improve server default comparison
  

  References: #787

• [bug] [autogenerate] [mysql] Fixed issue where autogenerate rendering of op.alter_column() would
  fail to include MySQL existing_nullable=False if the column were part
  of a primary key constraint within the table metadata.

  References: #788

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.