Issues

Issue #3067 resolved

Naming convention exception for Boolean type on PostgreSQL

Maik Riechert
created an issue
mybool = Column(Boolean, nullable=False, default=False)

I use PostgreSQL which has a native boolean type. If I then also use naming convention:

"ck": "ck_%(table_name)s_%(constraint_name)s",

Then sqlalchemy complains:

sqlalchemy.exc.InvalidRequestError: Naming convention including %(constraint_name)s token requires that constraint is explicitly named.

If I define the column as

isPublic = Column(Boolean(create_constraint=False), nullable=False, default=False)

it works, so I think this is a bug in which sqlalchemy doesn't connect the fact that there is a native Boolean and no constraint exists actually.

Comments (15)

  1. Mike Bayer repo owner
    • changed milestone to 1.0
    • changed component to sql
    • edited description
    • attached 3067.patch

    naming is obviously taking awhile to get off the ground. Stick with the workaround for now, this is sort of a behavioral enhancement IMHO, the attached patch defers out the naming until compile time. But I'm not sure if this throws off existing use cases, 1.0 for now...

  2. Maik Riechert reporter

    It will probably fail when using "alembic --sql" as there's no connection then. How should it know which SQL backend (mysql, postgresql,..) is used?

  3. Mike Bayer repo owner

    all databases have entirely different variants of DDL so --sql mode requires that a dialect be present just like in any other case, no problem there.

    not sure if I like this approach still as this means special steps need to be taken in order to read constraint.name. still haven't devised a solution to this which covers every base.

  4. Mike Bayer repo owner
    • Fix bug in naming convention feature where using a check constraint convention that includes constraint_name would then force all :class:.Boolean and :class:.Enum types to require names as well, as these implicitly create a constraint, even if the ultimate target backend were one that does not require generation of the constraint such as Postgresql. The mechanics of naming conventions for these particular constraints has been reorganized such that the naming determination is done at DDL compile time, rather than at constraint/table construction time. fixes #3067

    → <<cset d2193f53c10d>>

  5. Mike Bayer repo owner
    • Fix bug in naming convention feature where using a check constraint convention that includes constraint_name would then force all :class:.Boolean and :class:.Enum types to require names as well, as these implicitly create a constraint, even if the ultimate target backend were one that does not require generation of the constraint such as Postgresql. The mechanics of naming conventions for these particular constraints has been reorganized such that the naming determination is done at DDL compile time, rather than at constraint/table construction time. fixes #3067

    → <<cset d462dbde9976>>

  6. Log in to comment