8 komentáře “iBatis 3 is alive!

  1. 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.

  2. 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.

  3. 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?

  4. 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.

  5. 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?

  6. 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.

  7. 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.