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.
https://issues.apache.org/jira/browse/IBATIS-332 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! jay -- 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.
