ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jaybytez <jayby...@gmail.com>
Subject jdbcType/javaType accessibility in TypeHandler
Date Sat, 19 Aug 2006 00:44:42 GMT

I created this JIRA issue based on the TypeHandler and wanted to know if
anyone is having this issue.  It started out as an ehancement request but is
turning into a larger issue.


The setParameter method in TypeHandler makes jdbcType available...I like
it...but am not totally sure why its available..because it is not available
in any of the getResult methods.  So, if I create a TypeHandler for my
DateTime object (that deals with java.sql.Date and java.sql.Timestamp), I
can run a PreparedStatement setDate or setTimestamp based on the jdbcType
passed into the setParameter method.  But the jdbcType is not passed into
the getResult, so I will not be able to know which get method to call
(getDate or getTimestamp).  If I call getTimestamp on a DATE type, I get an
Oracle error.  So now instead of defining a global handler for my DateTime
object, I have to create two handlers....one for java.sql.Date to my
DateTime and one for java.sql.Timestamp to my DateTime)  and I cannot
register them as global since you register them by the javaType (not
jdbcType as I have assumed).  So I have to set the typeHandler in each of my
sqlMaps in every instance I use Date or Timestamp.

It would be a significant increase of functionality and limit the amount of
TypeHandlers needed if each setParameter and getResults had access to the
javaType/jdbcType (and I don't know in the iBatis API if it does).  

Also, as my entry in JIRA explains, I could create a TypeHandler for a
superclass and use the iBatis configuration (sqlMap jdbcType) to help me
instantiate the correct version of the class in the TypeHandler.  Instead, I
have to create a multitude of TypeHandlers for my TypeSafeEnumeration
objects (one for each type because the superclass does not know which
instance to Cast the class to, but it would know this through the javaType).

I am trying to find out the best solutions and so far the only viable one is
to move away from global handlers and always make specific ones that deal
with one specialized Java Type and only one specialized Jdbc Type.

But for instance in a BooleanTypeHandler (where char 'T' is true, where
String "true" is true, and where int 1 is true), this may store a char as a
VARCHAR and a String as a VARCHAR and an int as a INTEGER.  This works fine
in the setParameter.  But you are in trouble in the getResults because you
don't have access to the jdbcType defined in the sqlMap to know which
ResultSet .getXXX method you should call.  There is a little more
flexibility when dealing with other SQL Types (outside of Date/Timestamp)
since you can call (in getResult) ResultSet's getString and return most
datatypes as a String.  

Any thoughts on this?  Is this available?

I am finally integrating iBatis into the framework and I just don't want
this to be one of the concerns or questionable parts of the architecture
that some developers think is too confusing or combersome...creating
multiple TypeHandlers.

Thanks so much for all your development!

View this message in context: http://www.nabble.com/jdbcType-javaType-accessibility-in-TypeHandler-tf2130612.html#a5880443
Sent from the iBATIS - User - Java forum at Nabble.com.

View raw message