|
Thanks for the advice Mark, but what exactly are you recommending? I'll do whatever you tell us, I suppose Gavin, I guess the trick is that before MySQL-5.0, you can use whatever you want, preferably "BIT", because that works with MySQL-4.0 and MySQL-4.1, and ends up being a synonym for TINYINT(1), which the driver will treat as java.sql.Types.BIT. However starting with 5.0, the sql type "BIT" might not be the type people want, but "BOOLEAN" probably is. Since as far as I can tell, you don't have version-specific dialects for schema export purposes (I might be missing something though), I suppose skip it for now. Maybe HIB-3.1 could have version-specific schema export (you might want it for the new numeric types in Oracle 10g, and such too)? From the JDBC side of things either would work, the driver will map them to java.lang.Boolean in either case. If version-specific schema export isn't in the cards for awhile, maybe just a documentation note for schema export that MySQL-5.0 users might want to consider post-processing their schema files, converting BIT to BOOLEAN. Well, we do have version-specific dialects for some databases, so we could do the same for MySQL. Only problem is, we already have two dialects (MyISAM vs InnoDB), so this change would mean four MySQL-specific dialects. And it seems kinda a small thing I'm not sure... > And it seems kinda a small thing Gavin, you're probably right. Is there any MySQL-specific dialect documentation where we can spell that out? I think that would be the most flexible, final solution. The issue comes from the fact that not all storage engines will support the BIT type in 5.0 for awhile, so users get errors such as the following (which Matt Raible pointed out, which caused this report): https://appfuse.dev.java.net/servlets/ReadMsg?list=users&msgNo=6389 (fixed in MySQL-5.0.5 for everything but our cluster product right now, though). If we map Types.BIT to MySQL Boolean in the new MySQL5InnoDBDialect, that wouldn't be schema compatable with the other MySQL dialects. If a customer wants to create their own dialect, they could overide this mapping. Something easy like: " public class MySQLCustom extends MySQL5InnoDBDialect { public MySQLCustom() {
super();
registerColumnType( Types.BIT, "boolean" );
} Perhaps we will do something in a future Hibernate release so that customers could specify the mapping a different way. To bring this issue back to life: Can't we just map BIT to tinyint(1) in the MySQL dialect. This seems okay for all MySQL dialects (MyISAM and InnoDB). One of the problems with bit in MySQL is that standard it's not show in a MySQL console. For example: "select bitField from testTable" = field values not shown in console. You have to use "select BIT(bitField) from testTable" or "select bitField+0 from testTable" to show the values. When using tinyint(1), you don't encounter this problem. So please fix this. Hi gavin, My team is working with Seam and jboss 4.2 and discover this bug when we install our application on the pre-production plateform Our pre-production and production plateforms are in RHEL 5. Our developpement plateform is on RHEL 4. This bug is really annonying because :
Laurent Mallet To get booleans working without custom code this alias may be useful (works for MySQL -> HBM -> Java tooling): 1) represent booleans with TINYINT(1) 2) Add to cfg tinyInt1isBit=true & transformedBitIsBoolean=true: 3) if running hbm2hbmxml, hbm2cfgxml, hbm2java use jdbcconfiguration, not configuration One version set this worked on: JDK 1.5.0_09, Connect/J 5.1.6, Hibernate 3.2, Tools 3.2.2b1 > Can't we just map BIT to tinyint(1) in the MySQL dialect. This seems okay for all MySQL dialects (MyISAM and InnoDB). Me, too! I think this change does not affect seriously. |
||||||||||||||||||||||||||||||||||||||||||||||||
Looking through our manual, we're kind of being a bit goofy on this, as "BOOLEAN" doesn't exist in MySQL-4.0, so maybe BIT should be left, or you can somehow work in a comment in your docs about the issue.
4.0 is technically "in retirement", so maybe this can be revisited later this summer when 5.0 goes GA.