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?