[Mybatis Generator] MySql DATE and DATETIME handled the same way

[Nick Makes]

Hi,

I have two columns in a MySql database table: one is of DATE type and one is of DATETIME type.  When I run the generator, I see both corresponding Java fields mapped to java.util.Date type.  I expected the column of DATE type to instead be mapped to a java.sql.Date type.

This question might be related to my unfamiliarity with databases outside of MySql -- perhaps DATE is a full-fledged timestamp in other databases?  Anyways, when debugging, I can see the JDBC Type for my DATE column is '91' (i.e. Types.DATE), and the JDBC Type for my DATETIME column is '93' (i.e. Types.TIMESTAMP).

After looking through http://www.mybatis.org/mybatis-3/configuration.html#typeHandlers, I see there are two "default type handlers" listed for JdbcType.DATE: DateOnlyTypeHandler and SqlDateTypeHandler.

What is the recommended way of going about configuring Mybatis Generator to leverage SqlDateTypeHandler instead of DateOnlyTypeHandler for a JDBC type value of '91'?  I like the idea of setting this at the root configuration level, so as to avoid having to specify each and every DATE column with a <columnOverride /> element.  Can it only be done at the column level?  Any tips would be greatly appreciated here.

Thanks,

Nick

[Jeff Butler]

Yes - databases vary wildly in how they interpret DATE.  On Oracle, a DATE could be either date or date/time.

In my experience with MyBatis on lots of different databases, I consider it best practice to only use java.util.Date and then let the jdbcType direct MyBatis in how to handle the Date.  On my projects, using java.sql.Date is a grievous offense :)  My opinion is expressed in this code - but that's just me.

You can change it globally by creating your own implementation of org.mybatis.generator.api.JavaTypeResolver and registering it with <javaTypeResolver> in your <context>.

Jeff Butler

--
You received this message because you are subscribed to the Google Groups "mybatis-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mybatis-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Nick Makes]

Thanks Jeff for the explanation.

I agree with your aversion to using java.sql.Date anywhere in code as a Model's type, but I was looking at a marshalling issue I came across (with marshalling *Example objects) the wrong way.

What threw me off was the Example class method GeneratedCriteria#addCriterionForJDBCDate( String, java.util.Date, String ) in regards to my table that had a base column of DATE type (in MySql).  It saves that value as a java.sql.Date to the Criterion's Object value field.  Since I'm attempting to support XML/JSON marshalling for all generated types (and their associated primary keys & example classes), I had a custom deserializer taking my JSON date for the Object value field and setting it always as java.sql.Date.  Setting it always as java.util.Date doesn't seem to have broken the Example class from my tests, and got me past my issue.

Those Example classes are behemoths.  Super useful, just wish I had a better, intuitive understanding of how and why they do what they do.

Nevertheless, I'm no longer blocked.  Thanks again Jeff!

-Nick

[Jeff Butler]

Yeah - the example classes.  Sigh.  Mistakes were made.

What I'm doing there is using the java.sql.* types to force the correct type handler to be called - because I don't set the jdbcType attribute for those dynamically generated queries.  It would be a nice project to remake the example classes in a better way.  Maybe someday.

Jeff Butler