« What's the best way... | Main | What's a good DVI... »
20051019 Wednesday October 19, 2005

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
Click me to subscribe
Matt Raible is a Web Architecture Consultant specializing in open source frameworks.
« May 2012
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
  
       
Today

Recent Entries

Tag Cloud

abbie appfuse denver flex grails gwt hibernate jack java jsf linkedin maven myfaces rails roller skiing softwaresummit spring springmvc struts2 tapestry travel vacation webframeworks wicket