incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clinton Begin <>
Subject Re: Incubation of iBATIS Data Mapper
Date Mon, 09 Aug 2004 06:04:12 GMT
Hi Noel,

Thanks for your response.

For those who may not be familiar with iBATIS, it is a persistence tool. 
More specifically, it is a Data Mapper (PoEAA, Fowler).  iBATIS is not 
an Object Relational Mapper, however many people find it does a better 
job of isolating the object model from the data model than any ORM tool. 
  I sometimes refer to iBATIS as an SQL Mapper, because essentially, 
that's what it does.  It maps the interaction of the inputs and outputs 
of an SQL statement.

Here's a simple example that automatically maps column aliases to the 
object based on the JavaBean property names in the Address class:

   <select id="getAddress" parameterClass="int"
       ADR_ID           as id,
       ADR_STREET       as street,
       ADR_CITY         as city,
       ADR_PROVINCE     as province,
       ADR_POSTAL_CODE  as postalCode
     from ADDRESS
     where ADR_ID = #id#

This statement can be executed (i.e. an Address can be retrieved) by 
running this simple Java code:

   Integer pk = new Integer(5);
   Address address = (Address)sqlMap.queryForObject("getAddress", pk);

There is no complex JDBC or SQL embedded in the Java source.  iBATIS has 
a great deal of architecture behind it, including transaction 
management, caching, resource management, lazy loading, and even 
optional bytecode enhancement.  Furthermore, it supports mappings for 
more than just domain classes.  iBATIS can map to primitives, Maps, 
arrays, Collections and even XML (text or DOM).  It does all of this 
with a very short learning curve and a simple design.

I rarely compare iBATIS to any ORM tool such as OJB or Hibernate, as 
they are simply too different.  I will say though that iBATIS is much 
more tolerant of complex database designs that do not easily map to an 
object model.  This makes iBATIS an ideal choice for enterprise 
applications.  Additionally, due to its simple API and short learning 
curve, iBATIS is also an easy choice for small applications.

ORM tools still have some advantages when both the object model and data 
model are entirely within the control of the application developer.  I 
typically refer to this as an "application database" (as opposed to an 
enterprise database, legacy database or 3rd party database).  An 
application database is typically considered a part of the application, 
and is rarely accessed by other code or systems.  In these cases, ORM 
tools can still save developers a lot of time from writing SQL. 
Additionally, ORM tools by nature can more easily implement features 
such as object identity, smarter caching, dirty checking and 
disconnected sessions.

With regard to tools similar to iBATIS, I can only say that iBATIS seems 
to be truly unique in this space.   There is not a lot to compare it to. 
  Interestingly, one of the technologies with similarities to iBATIS is 
inline SQL.  Many languages support the concept of inline SQL (Forte, 
Pro*C etc).  Even Java has seen some level of inline SQL support through 
SQLJ.  One could think of iBATIS as "inline SQL for XML" (tongue in 
cheek).  iBATIS has many of the same benefits as inline SQL, but allows 
for a more robust architecture to be built around it.  It also makes for 
much cleaner code than inline SQL typically does. iBATIS seems to have 
inspired other projects in this space, most recently a tool called Mr. 
Persister.  This is a great sign that the concept has been accepted by 
the community. It is exciting to see such innovation in a space where we 
thought only ORM could live.

iBATIS has 2 years of production use under its belt and its user 
community reaches into the thousands.  There are already efforts 
underway for GUI tools, IDE plugins and Ant plugins.  iBATIS also has a 
C# edition, which is almost ready for a 1.0 release.  iBATIS will be one 
of the first truly multi-language persistence solutions.  Developers 
will be able to leverage their iBATIS skills on both the J2EE and .Net 

iBATIS has always been free and open source.  It has had a lot of 
community involvement since day one.  Half of our team has been using 
the product since the original release and has been contributing to it 
ever since.

My apologies for the extremely long post.  I hope it answered at least 
some questions.  More information can be found at the website:

JPetStore is the official example for iBATIS and should likely tag along 
as part of the iBATIS code base.

Best regards,

Clinton Begin

Noel J. Bergman wrote:
> Clinton,
> I see that you have Ted Husted and Harish Krishnaswamy backing your
> Incubation, as well as other enthusiastic people.  I see that our Jakarta
> Commons Mapper project(
> has support for iBatis as well as other data mappers.  And you might want to
> talk with our DB project and see what interest also comes from there.  Are
> you familiar OJB (
> We also had a proposal from Robert McIntosh for something called Chameleon.
> See:
> .org&msgId=1702588 for information on that proposal.  Chameleon ran into a
> problem in that support hasn't emerged for it, but I am cc'ing Robert in
> case there are some emerging synergies.
> Would you compare and contrast iBatis with other similar technologies for
> people who aren't yet familiar with iBatis?
> 	--- Noel
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message