Matt RaibleMatt Raible is a Java Champion and Developer Advocate at Okta. developer.okta.com

The JHipster Mini-Book The JHipster Mini-Book is a guide to getting started with hip technologies today: Angular, Bootstrap, and Spring Boot. All of these frameworks are wrapped up in an easy-to-use project called JHipster.

This book shows you how to build an app with JHipster, and guides you through the plethora of tools, techniques and options you can use. Furthermore, it explains the UI and API building blocks so you understand the underpinnings of your great application.

For book updates, follow @jhipster-book on Twitter.

10+ YEARS


Over 10 years ago, I wrote my first blog post. Since then, I've authored books, had kids, traveled the world, found Trish and blogged about it all.

MySQLDialect vs. MySQLInnoDBDialect

I've used Hibernate's MySQLDialect ever since I started using Hibernate and MySQL. However, I noticed with Hibernate 3 there's a couple of new MySQL Dialects in town: MySQLInnoDBDialect and MySQLMyISAMDialect. Using MySQLDialect still seems to work fine for me - and it handles transaction rollbacks when I'm using InnoDB types.

What's the point of these fine-grained dialects? Should they be used when possible, or does MySQLDialect default to one of these based on MySQL metadata? IMO, Hibernate's javadocs could stand to have a little more "doc" action. Maybe I'm just not looking in the right place for the answer to this question.

Posted in Java at Oct 19 2005, 08:53:16 AM MDT 5 Comments
Comments:

As far as I know, when you use MySQLInnoDBDialect, the schemaexport ant tag generates a "type=InnoDB" after each create statement.

Posted by Nicolas Cornaglia on October 19, 2005 at 09:23 AM MDT #

The right place to look would probably be the source :) As the previous post states, the MySQLMyISAMDialect dialect adds "type=MyISAM" and MySQLMyISAMDialect adds a "type=MyISAM" clause to the create statement. Other differences are the unlike the other MySQL dialects, MySQLMyISAMDialect does not drop the constraints in the generated drop schema script. dunno why.. Finally the hasSelfReferentialForeignKeyBug = true value MySQLInnoDBDialect seems related to nullifying values on entities that have self referential integrity constraints during deletes.

Posted by 64.26.193.89 on October 19, 2005 at 09:53 AM MDT #

Thanks guys - that makes sense. I've been configuring my whole MySQL instance to use InnoDB - so that's why I haven't needed it. Sounds like I should change to using MySQLInnoDBDialect in AppFuse.

Posted by Matt Raible on October 19, 2005 at 03:46 PM MDT #

Shouldn't it be named "MySQLOracleDialect" now ;)

Posted by Thomas Risberg on October 19, 2005 at 07:39 PM MDT #

I haven't used either of the Hibernate MySQL dialects but the answer regarding setting the table type sounds right. I believe if the InnoDB table type is used it requires setting a couple of server options that are not set by default, so even if the MySQLInnoDBDialect is used it may also required modify the server configuration file before creating the database. There is also a bug in earlier implmentations of a MySQL jdbc driver in detecting whether or not the database supports transactions. The driver was checking the version of the database and setting supportsTransactions to true if the version number was after the one at which Innodb table support was added. However, as the default table type is MyIsam a specific database instance or table would still not support transactions even thought the supportTransactions method was saying that it did.

Posted by John Fereira on October 23, 2005 at 07:22 AM MDT #

Post a Comment:
  • HTML Syntax: Allowed