iBatis 3 is alive!

9. 2. 2009

I had a discussion with Jira recently, whether we could be still looking forward to iBatis 3. It has been long time since iBatis 3 Whiteboard was seriously touched and I haven't found any other clue when or whether there is going to be iBatis 3. There is very small activity for 3.x version in Jira, though there were some commits into iBatis 3 core. As I am going to have a speech in University Hradec Králové on iBatis, I have decided to ask directly its authors about this issue.

The answer I've received and considered very delighting I quote on following lines:

Hi Jan,

Let me address a few of your assertions, and then I can give you an update:

First, Kai is right, iBATIS 2 has reached it's "feature completeness" -- we won't add any new significant features to it. We'll maintain it and fix bugs.
As far as Java 5 goes, iBATIS 2 supports Enums and Generics as well as iBATIS 3 ever will (with the exception of interface binding, which will benefit from generics and annotations).
The iBATIS 3 Whiteboard hasn't been touched because it too is complete. It's purpose was to gather thoughts and provide a forum for debate.
What I guess hasn't been communicated is that development of iBATIS 3 is well under way, and nearing a Beta release. We should put up a blog for this... long overdue.
You can find the iBATIS 3 source here: http://svn.apache.org/repos/asf/ibatis/trunk/java/ibatis-3/

The core of iBATIS 3 is complete and in fact it runs the full suite of iBATIS 2 and JPetStore 5 unit tests, as well as its own comprehensive suite of tests. The new XML structure has been implemented and is far less verbose than the current one. Many improvements have been made to the core implementation of mappings, auto mappings, join mapping, caching, transaction management, batching, autocommit (real autocommit) and many other areas of the framework have been greatly improved and modernized.

The features remaining to be implemented at this time are:

Interface Binding
Annotation based configuration
New Dynamic SQL

Beyond that it will need some volunteers for Q/A and performance testing. It's a complete rewrite and one would be hard pressed to find a single method shared between the two.

I don't have an ETA, as I'm very busy. But we should see significant new progress made by the end of February.

I'll see if we can get a team blog up, possibly to replace the homepage so that we can report more regularly on the status.

Cheers,
Clinton

Finally, there is no doubt what situation is around iBatis. I hope that you are as glad as I am.

And it there are any volunteers among you to provide Q/A and performance testing, just subscribe to iBatis mailing list and contact Clinton Begin.

Komentáře

Otec Fura 19.2.2009 21:35

Maybe this mail thread could save us a lot of discussing:

http://www.mail-archive.com/ibatis-user-java@incubator.apache.org/msg01239.html

Those two posts from the thread I’d like to point out the most (they directly connect to our discussion):

http://www.mail-archive.com/ibatis-user-java@incubator.apache.org/msg01241.html http://www.mail-archive.com/ibatis-user-java@incubator.apache.org/msg01251.html

I couln’t say it better, especially when having only little experience with Hibernate.

Otec Fura 19.2.2009 20:56

I understand what you try to explain to me. iBatis is not the right tool when you need such things. On the other hand look around the web and tell me how many web applications focusing on broad public require editing complex object trees in single transaction? Even if I look at the Facebook that is pretty complex application I don’t see much use cases of such type. So the final thought of mine is, that in certain domains we could be more or less sure, that we wouldn’t get into a situation you describe at the end. Partly it’s also matter of UI design - whether complex editation is allowed or not. Look at websites that we make:

http://www.g2.cz http://www.trotina.cz http://www.cez.cz http://www.frekvence1.cz http://www.cilichili.cz/ https://secure.plobergerhotels.com/maximilian/reservation.html

No complex object trees were needed. Some of those applications we have supported and extended for several years and technology still suffices.

On the other hand if I had to make an accounting application or company information system, I would probably go the JPA way. Because the task is diametrically different.

Lubor 19.2.2009 17:50

Imagine for instance that we have object tree that consists of five objects mapped to five different database tables. This object tree is used during user interaction and user can modify properties of any of these objects. At the end of the user interaction we need to update that object tree to persist all changes made by the user. But without dirty checking we don’t know which of those five objects has been modified and which hasn’t so we always have to send five updates to database. Maybe there wasn’t any modification at all, but we still have to hit database five times. With more complex domain object models this problem can be even more obvious.

I understand that IBatis has better learning curve and can save you some effort, but it sounds to me that it can bring you a lot of headaches during performance tuning when you discover that your application doesn’t scale very well.

Of course that you don’t have care about all these details if your application is using very simple flat domain object model because performance impact won’t be significant in that circumstances. But who will guarantee that application requirements won’t change in the future and that your application won’t have to support much complex object model? Will you then rewrite your persistence layer or mix two different persistence tolls?

Otec Fura 18.2.2009 13:26

iBatis unit of work is single SQL statement. If you want to store object tree, you have to decide yourself what needs to be stored and what does not and call iBatis function appropriately. Even transaction demarcation is done “manually” - iBatis won’t decide what will run in transaction and what does not (of course in combination with Spring we use declarative transaction management).

For the purposes of our web presentation is the functionality of iBatis sufficient. We don’t need to modify complex object trees on several places at once and store them from the top. When we have complex object tree, we usualy work with its decomposed parts, so the objects we work with are quite simple. So why bother?

Yes, there is some overhead in the sense, that we always update whole record and not only columns with modified data - but I think that this is not a major problem. When there is huge data involved there we usualy define two update statements so that we can avoid unnecessary tranfer of such data.

As I said earlier - iBatis is not magic almighty super duper engine as for example Hibernate is. It is simple - saves you a lot of work, but leaves all important decisions up to you. On the other hand, there is a little what could go wrong comparing to Hibernate.

Lubor 18.2.2009 12:49

But what about performance impacts then? If iBatis doesn’t support dirty checking, during update operations it’s not able to detect what part of object tree has been modified and therefore full update has to be used (what can be significant performance overhead). Is iBatis meant to be used for simple flat domain object models only? Or are there any techniques that can be used to optimize database communication in case that your application requires complex domain object models?

Otec Fura 18.2.2009 08:01

I don’t want to talk for authors but I don’t think so. Judging from the iBatis philosophy, where you are the author of SQL queries, framework is not eligible to modify / generate your SQL updates (that would be necessary to provide dirty checking). I think, that if you need such functionality JPA is the way you should follow. iBatis is more valuable when you want to keep full control over your SQL communication mechanism than when you want to minimize your work. Full control, reliability and simplicity are the values we appreciate.

Lubor 18.2.2009 02:23

Does anybody know if iBatis 3 will support dirty checking and cascading by any chance? IMHO usability of any persistence tool without dirty checking is quite limited.

Jira 9.2.2009 20:37

Really great to hear such a great news… I think I’m not the only one looking forward to.