similarity index 80%
rename from meta-python/recipes-devtools/python/python3-alembic_1.20.0.bb
rename to meta-python/recipes-devtools/python/python3-alembic_1.20.1.bb
@@ -4,7 +4,7 @@ LIC_FILES_CHKSUM = "file://LICENSE;md5=ff111c41e8748bbfa45e8ba92347b681"
inherit pypi python_setuptools_build_meta
-SRC_URI[sha256sum] = "db505480647bc60386c5369402f4a57a506b7539c9e9ef5e270d45cbbe4939bf"
+SRC_URI[sha256sum] = "83490def1f723413db5096591f7609ac52544805be93849170088ed04f5a2e0b"
RDEPENDS:${PN} += "\
python3-dateutil \
Upgrade to release 1.20.1: bug: - [bug] [autogenerate] Fixed issue where a table or column comment set to an empty string would cause autogenerate to detect a comment change on every run. As most backends, including PostgreSQL, MySQL, MariaDB and Oracle, don't store an empty string comment distinctly from no comment, autogenerate now treats an empty string comment the same as None when comparing comments. Additionally, an empty string comment is now rendered in op.create_table() and op.add_column() directives, where it was previously omitted. Pull request courtesy vineoy. - [bug] [autogenerate] [postgresql] Fixed rendering of the PostgreSQL ~sqlalchemy.dialects.postgresql.DOMAIN type in autogenerated migration scripts. Previously the type was rendered using repr(), which omitted the check, not_null, default, collation, constraint_name, schema and create_type arguments and did not apply a dialect prefix to the underlying data type. The full set of arguments is now rendered and the underlying data type is rendered using the standard type-rendering logic. Pull request courtesy Sebastian Cao. - [bug] [autogenerate] [postgresql] Fixed false-positive "Computed default cannot be modified" warning emitted during autogenerate when comparing PostgreSQL Computed columns whose reflected SQL expression includes type cast specifiers such as ::regconfig or ::text, which PostgreSQL adds to the expression as stored. These cast specifiers are now stripped before comparison so that otherwise equivalent expressions no longer trigger the warning. Pull request courtesy Sebastian Cao. - [bug] [autogenerate] [postgresql] Fixed issue where autogenerate would detect an unchanged PostgreSQL expression-based index as modified when the expression included type casts, such as a cast to a type with a length or precision, a nested cast, or a cast followed by a DESC modifier. - [bug] [postgresql] Fixed bug where Operations.alter_column() against a PostgreSQL identity column would render an incomplete, invalid ALTER TABLE ... ALTER COLUMN statement with no clause at all when existing_server_default was omitted, even if there were no existing server default. Pull request courtesy Riti Grover. - [bug] [environment] Fixed issue where a third party plugin published using the alembic.plugins entrypoint, configured to refer to a plugin module as documented at alembic.plugins.toplevel, would cause import alembic to fail with a TypeError, as the loaded module was erroneously iterated rather than being set up directly. An entrypoint that refers to a collection of modules, the form which inadvertently worked previously, continues to be accepted but now emits a deprecation warning. - [bug] [autogenerate] Fixed issue where dialect-specific keyword arguments on a ForeignKeyConstraint, ForeignKey or CheckConstraint, such as postgresql_not_valid, were not rendered for the constraints that are part of an autogenerated Operations.create_table() directive, nor for an autogenerated Operations.create_check_constraint() directive. The Operations.create_table() case additionally requires SQLAlchemy 2.0.55 / 2.1.5 or greater. - [bug] [autogenerate] Fixed issue where, when using SQLAlchemy 2.1, the CHECK constraint generated by a type such as ~sqlalchemy.types.Enum or ~sqlalchemy.types.Boolean with create_constraint=True would be rendered by autogenerate as explicit sa.CheckConstraint() entries within op.create_table(), in addition to the type itself which already produces that constraint, leading to a duplicate constraint error when the migration is run. - [bug] [operations] Fixed issue where a CreateTableOp produced from an existing ~sqlalchemy.schema.Table using CreateTableOp.from_table() would emit the CHECK constraint generated by a type such as ~sqlalchemy.types.Enum or ~sqlalchemy.types.Boolean with create_constraint=True twice in the resulting CREATE TABLE statement when invoked directly. Signed-off-by: Leon Anavi <leon.anavi@konsulko.com> --- .../{python3-alembic_1.20.0.bb => python3-alembic_1.20.1.bb} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename meta-python/recipes-devtools/python/{python3-alembic_1.20.0.bb => python3-alembic_1.20.1.bb} (80%)