Hello,

I would like to customize the MySQL dialect (e.g. the MySQL5InnoDBDialect) so that it uses a TINYINT(1) column type for a Boolean property, instead of BIT(1).

I looked at the class "org.hibernate.dialect.Dialect" and found



This is the only place where I could find something with "boolean".

Now I thought I might just add a



But "Types.TINYINT" is already "mapped" to "Hibernate.BYTE.getName()" some lines below, and that would overwrite the association for "Types.TINYINT".


Does anyone have a hint, how to alter the dialect class to use a TINYINT(1) column type for Boolean class properties?


Thanks a lot for your help!

Do something like following:



Then use your new "MySQLCustomDialect" as your dialect.

Hello r,

thanks a lot for your answer. So, it is that easy :)

I think I had the wrong approach. So, BOOLEAN will be mapped to the "internal" Types.BIT, and with your modification, the "Types.BIT" will use the column type "TINYINT(1)", overwriting the "registerColumnType( Types.BIT, "bit" );" from "org.hibernate.dialect.MySQLDialect" (understood correctly?)

One last question please:

Is the custom Dialect with "TINYINT(1)" for a boolean value "compatible" with the standard "MySQL5InnoDBDialect" using "BIT" for a boolean value, so that I can save an object with "MySQLCustomDialect" and load it with "MySQL5InnoDBDialect" (assuming that there is some smart handling when Hibernate finds a "0" or "1" as the column value when translating it to a boolean property)?

I am not sure what you are going to do, but I think the answer is yes.

Well, I just want to do what I initially wrote - I want TINYINT(1) as the column type for boolean values (which you already solved :) ), because this is more common in the MySQL area instead of using BIT (for example, the famous HeidiSQL MySQL Frontend even does not display BIT values, and there is just no need to fix this bug, because the majority seems to use TINYINT(1)).

The question about the compatibility is just out of curiosity; maybe I use the custom dialect, and another one writes a test case and "forgets" to configure that custom dialect; will this lead to an error or not. But this is, of course, a minor issue which I can test for myself.