MySQL Boolean autogenerate comparson to TINYINT

[johaven]

Alembic version: 1.2.1
SQL: MariaDB

Each upgrade (with compare_type enabled) duplicate constraints :

paid = db.Column(db.Boolean)
satisfaction = db.Column(db.Boolean)

  CONSTRAINT `CONSTRAINT_1` CHECK (`paid` in (0,1)),
  CONSTRAINT `CONSTRAINT_2` CHECK (`satisfaction` in (0,1)),
  CONSTRAINT `CONSTRAINT_3` CHECK (`paid` in (0,1)),
  CONSTRAINT `CONSTRAINT_4` CHECK (`satisfaction` in (0,1)),
  CONSTRAINT `CONSTRAINT_5` CHECK (`paid` in (0,1)),
  CONSTRAINT `CONSTRAINT_6` CHECK (`satisfaction` in (0,1)),
  CONSTRAINT `CONSTRAINT_7` CHECK (`paid` in (0,1)),
  CONSTRAINT `CONSTRAINT_8` CHECK (`satisfaction` in (0,1)),
  CONSTRAINT `CONSTRAINT_9` CHECK (`paid` in (0,1)),
  CONSTRAINT `CONSTRAINT_10` CHECK (`satisfaction` in (0,1)),
  CONSTRAINT `CONSTRAINT_11` CHECK (`paid` in (0,1)),
  CONSTRAINT `CONSTRAINT_12` CHECK (`satisfaction` in (0,1)),
  CONSTRAINT `CONSTRAINT_13` CHECK (`paid` in (0,1)),
  CONSTRAINT `CONSTRAINT_14` CHECK (`satisfaction` in (0,1)),
  CONSTRAINT `CONSTRAINT_15` CHECK (`paid` in (0,1)),
  CONSTRAINT `CONSTRAINT_16` CHECK (`satisfaction` in (0,1)),
  CONSTRAINT `CONSTRAINT_17` CHECK (`paid` in (0,1)),
  CONSTRAINT `CONSTRAINT_18` CHECK (`satisfaction` in (0,1))

[zzzeek]

this is because compare_type does not detect a MySQL TINYINT column as the same as Boolean, so you will need to adjust these migrations manually or use a custom type comparator.

there is then a second issue that when "changing" the type of the column, it does not drop the old constraint.

unfortunately there is no good way to automate these things and I have no means of fixing this issue in the near future.

[zzzeek]

this is not specifically "enums" but this is the same area of issue.

[johaven]

I do not understand totally because logically when doing the upgrade there is a conversion to the SQL language based on the type of database, no? Starting from this idea, it is possible to compare what has been generated in SQL and the structure of the table (for example via a "show create table"). I am wrong ?

[zzzeek]

MySQL has a datatype called "TINYINT". You can use this datatype directly in your schema, but it is not a SQL standard type; only MySQL has it. SQLAlchemy has a datatype called "Boolean" that generates any number of different datatypes on databases, depending on what capabilities they have. On SQL Server, it uses BIT; on Postgresql, BOOLEAN, on MySQL, TINYINT.

The thing is you can use TINYINT / BIT / etc. without them corresponding to SQLAlchemy's Boolean.

Alembic therefore does not, at the moment, make the assumption that if a metadata model has Boolean, and the target database has TINYINT, that this TINYINT is the same datatype.

This is 100% a bug, because even if the user did use TINYINT(display_width=1), and then changed their column to Boolean, that should not produce a change in datatype.

That part of this is not too difficult to fix but needs a comprehensive approach and tests throughout the library to fully release.

However, with all of that, the situation gets much worse. SQLAlchemy's Boolean and Enuim datatypes also generate CHECK constraints, which is a decision I would never have made today if I could have seen these issues coming. There's no autogenerate support for CHECK constraints either, and this would be very difficult to do generically. However, again in the case of Boolean / Enum, we should be taking a bit of a guess that there likely is a CHECK constraint on the table when these datatypes are used. However, that is also quite complicated because these CHECK constraints have no particular name (they are unnamed by default and as you can see MySQL just generates a name), and we'd have to basically search for them and parse their SQL text on a per-database basis in order to identify the ones that we think are relevant to our particular database column.

So we can solve your immediate issue here with the first part of this but there's a longer term problem in locating and finding these CHECK constraints, such as if you changed your database type from Boolean to INTEGER, we'd need to DROP that constraint.

[johaven]

I understand the difficulty now, thank you very much for the explanation.

The best solution (for now) would be to disable the creation of constraints when desired.
There is an option that allows this when declaring a field like Boolean (https://docs.sqlalchemy.org/en/13/core/type_basics.html#sqlalchemy.types.Boolean).

I tested it on my fields:

paid = db.Column(db.Boolean, create_constraint=False)
satisfaction = db.Column(db.Boolean, create_constraint=False)

But this does not work currently in alembic, the constraints are still created :(
Independently i have this error when i use the create_constraint option:

/../sqlalchemy/sql/base.py:299: SAWarning: Can't validate argument 'create_constraint'; can't locate any SQLAlchemy dialect named 'create'
  % (k, dialect_name)

[zzzeek]

that's an argument of boolean:

Boolean(create_constraint=False)

[johaven]

Sorry, i am tired 😅 , it works with correct initialization:

paid = db.Column(db.Boolean(create_constraint=False))
satisfaction = db.Column(db.Boolean(create_constraint=False))