MySQL differentiates different "sizes" of LOBs. Apparently, the smaller types offer no storage benefit nor performance gain. So we should consider mapping the LOB types in the MySQL dialect to the LON variants in all cases.
The current setup causes truncation headaches for users, apparently unnecessarily.
Just a quick comment validating Steve's approach, since we discussed this in IRC on freenode and I asked around internally (and went through the source of the server), and this is indeed the case. The different BLOB/TEXT types seem to be designed to prevent storage over-allocation, since MySQL doesn't have CHECK CONSTRAINT.
Right, specifically the discussion revolved around the default environment should be something that "just works". For those that need to be cognizant of this, it is easy enough to supply a custom dialect reverting to the current behavior.
applied to trunk
I just upgraded from 3.2.x to 3.3.x (yes, a bit late, I know) and found my generated schema changing types under me. OK, that I more-or-less expected.
But I did expect that I ought to be able to override Hibernate's default decisions using <property length="NNNN"/>.
I've got no problem with changing the default to be the long* variants, but surely an explicit length request should still select the most appropriate MySQL type?
Mark, I noticed that the fix to MySQLDialect.java commented out:
// registerColumnType( Types.VARCHAR, 16777215, "mediumtext" );
// registerColumnType( Types.VARCHAR, 65535, "text" );
but did not comment out the following:
registerColumnType( Types.VARBINARY, 16777215, "mediumblob" );
registerColumnType( Types.VARBINARY, 65535, "blob" );
Should these also be commented out?