Skip to content

fix(autogenerate): exclude type-bound check constraints from reflected comparison - #1863

Closed
mturac wants to merge 1 commit into
sqlalchemy:mainfrom
mturac:fix/issue-1859
Closed

fix(autogenerate): exclude type-bound check constraints from reflected comparison#1863
mturac wants to merge 1 commit into
sqlalchemy:mainfrom
mturac:fix/issue-1859

Conversation

@mturac

@mturac mturac commented Sep 2, 2026

Copy link
Copy Markdown

Summary

  • Enum/Boolean columns with create_constraint=True generate type-bound check constraints
  • The metadata side correctly excludes these via all_table_check_constraints(), but the reflection side still returns them from the database
  • This causes false remove_constraint operations even when the table was created from the exact same metadata

Changes

  • Added type_bound_check_constraint_names() in sqla_compat.py to collect names of type-bound constraints from metadata
  • Filter reflected constraints by these names in _compare_check_constraints() before comparison
  • Added tests for both Boolean and Enum type-bound constraint scenarios

Test plan

  • test_existing_type_bound_boolean_not_detected — verifies no false diff for Boolean(create_constraint=True)
  • test_existing_type_bound_enum_not_detected — verifies no false diff for Enum(create_constraint=True, native_enum=False)
  • Existing check constraint tests still pass

Closes #1859

…d comparison

When Enum/Boolean columns have create_constraint=True, SQLAlchemy
generates type-bound check constraints. The metadata side already
excludes these via all_table_check_constraints(), but the reflection
side still returns them from the database, causing false
remove_constraint operations.

Add type_bound_check_constraint_names() to collect the names of
type-bound constraints from metadata, and filter them out of the
reflected constraint list before comparison.

Closes sqlalchemy#1859
@sqla-tester

Copy link
Copy Markdown
Collaborator

Hi, and thanks for the pull request!

This project accepts pull requests only for issues that a maintainer has already marked with the open for pull requests label. That way we can settle on an approach before anyone spends time writing code.

This pull request references issue #1859, which hasn't been marked open for pull requests, so the change isn't authorized yet and I'm closing it automatically. Once a maintainer adds the label to #1859, reopen this pull request and it will stay open. If #1859 needs more detail before that can happen, a complete runnable example is usually the missing piece, and adding one to the issue is the fastest way to get there.

This is automatic and procedural. It isn't a judgment on your change, and nothing you've written here is lost.

Thanks for your interest in the project!

@sqla-tester sqla-tester closed this Sep 2, 2026
@zzzeek

zzzeek commented Sep 2, 2026

Copy link
Copy Markdown
Member

cc @CaselIT

@CaselIT

CaselIT commented Sep 2, 2026

Copy link
Copy Markdown
Member

it doesn't really solves anything, since the issue with unnamed constraint in the metadata that came back named from the db is not solved ad all

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Autogenerate reports false remove_constraint for Enum/Boolean(create_constraint=True) columns

4 participants