iBatis.. i whatis

You read that correctly iBatis. “It is a persistence framework which automates the mapping between SQL databases and objects in Java, .NET, and Ruby on Rails. In Java, the objects are POJOs (Plain Old Java Objects). The mappings are decoupled from the application logic by packaging the SQL statements in XML configuration files. The result is a significant reduction in the amount of code that a developer needs to access a relational database using lower level APIs like JDBC and ODBC.“ (http://en.wikipedia.org/wiki/IBATIS)

According the WIKI it is best used when the developer “does not have full control over the SQL database schema”. For the project I am currently working on nothing can be truer, as one of the developers we have little control of the database and sometimes the SQL that is executed.
So why am I writing about it, well in the past month or so I have gotten a crash course into this framework as a decision was made to remove Hibernate and replace it with iBatis. The reasons were many and I will not go into them now as personally I feel better about it.

One of the main advantages in my book is the simplicity of this mapping: Basically you read in a configuration file that has the mapping files in it. This mapping file is in XML (I am not sure if that is a pro or a con yet) that houses SQL that is right not HQL or something else actual SQL. This file also contains the actual mappings that list out the input/output parameters and how they relate to the query. These parameters can be in a MAP or a POJO. I have used both so far, and have done other items which I found very difficult and frustrating with Hibernate (this could be because of my lack of knowledge into Hibernate).

So let’s get into a little bit of code OK so complicated code always hate examples that are simply Hello World why not go the extra mile and show something useful for once. In our application we call store information that the user may have entered, we create an XML document and store it in the DB as a CLOB. With Hibernate we were getting the data from the UI and then creating and XML document or getting the information from the DB and then having to parse it out into our POJOs. With iBatis we did things a bit differently; we removed the creation and parsing of the XML document into a callback handler. This handler implemented TypeHandlerCallback and basically either parsed the CLOB into the correct POJO or created the XML document based on the data from the UI without the need of the application developer ever having to call it.
Here is a row from our mapping document for the input parameter:

<parameter property="userData" jdbcType="clob" typeHandler="com.xyz.dao.UserDataCallbackHandler" />

Output Parameter looks very much the same:

<result property="userData" column="USER_DATA_CLOB" jdbcType="clob" javaType="com.xyz.vo.UserCriteriaVO" typeHandler="com.xyz.dao.UserDataCallbackHandler"/>

I want to look at the result as it is a bit more complicated than the parameter.


property – maps to the field in the POJO that will hold this column


column – is the actual DB column name that is returned from your query


typeHandler – this is the definition of the callback handler





Here are some interesting items to note:

• The typeHandler must be the fully qualified name. In some areas of mapping file you can alias the object but this is not one of those areas.

• The type handler cannot be the DAO, I tried to make it so I did not have to create a new class but iBatis had issues so a separate class had to be created.

I have ended up using the Callback Handler in numerous places where I want a conversions done or other cases complex object built.