Starting with Hibernate ORM 5.2.8, MariaDB gets its own Hibernate dialects.
Why?
While working on the new MariaDB Dialects, I realized that the MySQL Dialects would benefit from simplifying the version hierarchy.
Previously, the MySQL Dialects used to looks like that:
As you can see, because of the various MySQL storage engines (e.g. MyISAM and InnoDB), the class hierarchy has diverged in multiple branches. Once we integrated Hibernate Spatial, the MySQL Dialects have become even more convoluted.
For this reason, we created the HHH-11473 Jira issue, which is fixed in Hibernate 5.2.9.
How do we stand now?
After refactoring, the MySQL Dialects look as follows:
The following Dialects have been deprecated, therefore, they were not added to the class diagram above:
MySQLMyISAMDialect
-
Use
MySQLDialect
instead, as well as thehibernate.dialect.storage_engine=myisam
Environment Variable or System Property. MySQLInnoDBDialect
-
Use
MySQLDialect
instead, as well as thehibernate.dialect.storage_engine=innodb
Environment Variable or System Property. MySQL5InnoDBDialect
-
Use
MySQL5Dialect
instead, as well as thehibernate.dialect.storage_engine=innodb
Environment Variable or System Property. MySQL57InnoDBDialect
-
Use
MySQL57Dialect
instead. MySQL5InnoDBSpatialDialect
-
Use
MySQL5SpatialDialect
instead, as well as thehibernate.dialect.storage_engine=innodb
Environment Variable or System Property. MySQL56InnoDBSpatialDialect
-
Use
MySQL56SpatialDialect
which defaults to InnoDB by default.
The MySQLStorageEngine
abstraction encapsulates the difference between various storage engines,
By delegating this responsibility to a new abstraction, the MySQL Dialect hierarchy got a lot simpler.
Traditionally, MySQL used the non-transactional MyISAM
storage engine, and this is the default storage engine for all Dialects that are older than MySQL55Dialect
.
From MySQL55Dialect
onwards, the InnoDB
storage engine is used by default.
You can always override the default storage engine by providing the hibernate.dialect.storage_engine
Environment Variable or System Property.
Unlike other Hibernate configuration properties, this one must not be provided via persistence.xml
because the Dialect is bootstrapped prior to the configuration management mechanism.
Conclusion
The deprecated Dialects will be available for a while, but they will surely be removed in a future version of Hibernate, so you better use the new ones instead. This refactoring is useful for two reasons. First, supporting MySQL 8.0 requires a single Dialect, not two. Second, it’s easier for our users as well since the choice is much more straightforward now since there is only one Dialect associated to a given MySQL version.