In spite of modern JPA implementations, object-relational mapping is still "the Vietnam of our industry". Complex mapping configurations and performance problems are common for many projects, even with experienced developers. After refactoring and tuning we usually get things running. But this always takes time, money and compromises. Kauklahti is an open source tool aiming to keep ORM simple. It integrates with Spring JdbcTemplate and works like BeanPropertyRowMapper. But it also supports table joining and full CRUD generation. Kauklahti does not use xml or annotations. It provides simple programmatic API. Every piece of SQL is in coders hands before execution. Kauklahti persistence layer is highly visible, easy to run, test and debug. Log4j is the only required dependency, using Spring is optional. We've just replaced Hibernate with this simple 1300 LOC library in a mid-size project. More about Kauklahti in this blog http://blog.devtrain.fi/2009/10/18/kauklahti-making-orm-simple

Dreamsource ORM has this ideal for a long time. Please see http://code.google.com/p/dreamsource-orm/. Polymorphic query is under development, which is requested compared to Hibernate. Jim

Looking at the "Making ORM Simple" blog posting, things don't appear to be as simple to me as they could be. The "simple" explanation of Kauklahti takes up 5 vertical screens of my browser.

I can explain db4o with just one line of code: database.store(guitar); That's all. No tables. No mapping. No SQL. No JDBC. No ResultSetExtractor. No need to set up and maintain a relational database. db4o manages it's internal class schema and it's indexes while you store objects and it adopts to refactorings. If you really want simple object persistence, consider trying out an object database. -- Carl Rosenberger db4o team Versant Corp

Looking at the "Making ORM Simple" blog posting, things don't appear to be as simple to me as they could be. The "simple" explanation of Kauklahti takes up 5 vertical screens of my browser.

I can explain db4o with just one line of code:

database.store(guitar);

That's all. No tables. No mapping. No SQL. No JDBC. No ResultSetExtractor. No need to set up and maintain a relational database.

You are comparing apples to oranges. Kauklahti is a mapping tool, starting with fact that for some reason you have to use a relational database. You are selling an object database. There are more issues with object databases than just one object store method. We always encapsulate common lines of code in BaseDAO (or similar), so in concrete DAO class we just write: store(guitar);. But this alone does not explain anything about my framework or your product. So this is not relevant. However, I personally like the DB4O appoach. But I haven't had a chance to use it in a real project, so I don't know how it would really work. Our customers always have RDBMS and all tools and reporting are using that.

 Karo silimi çini silimi  Dizayn Restorasyon Karo Silimi Karo Silimi hakkinda teknik bilgiler. Granit Silimi Granit Silimi hakkinda teknik bilgiler.

 

 

What do you mean by

"the Vietnam of our industry"

? I don't get your point here.

What do you mean by

"the Vietnam of our industry"

?
I don't get your point here.

The war you cannot win. http://www.codinghorror.com/blog/archives/000621.html

What do you mean by

"the Vietnam of our industry"

?
I don't get your point here.

The war you cannot win.

http://www.codinghorror.com/blog/archives/000621.html

I'm not sure I buy this. I'm finishing up a Hibernate-based project after having been away from it for a few years and I've been thinking about this a lot. I definitely have had issues with Hibernate. Mostly, I solved them by not using any caching at all. Not even first level. Based on this experience, I think a lot of the issue with ORM is not the mapping. I agree that creating something that can mapping all possible object models to all possible relational models is probably not feasible without a Turing-complete language. But the reality is that we don't really have that problem. By and large, mapping is fairly straightforward. There is a small number many real-world scenarios to deal with. What I see issues with is the idea that the object and the database are the same thing. That is, if you look at the object, you are looking at the database, if you update the object you update the database. If you take that assumption away and think about objects as snapshots of data, a lot of the complexities disappear.

What I see issues with is the idea that the object and the database are the same thing. That is, if you look at the object, you are looking at the database, if you update the object you update the database. If you take that assumption away and think about objects as snapshots of data, a lot of the complexities disappear.

I prefer to see the other way around. Persistent image is a snapshot of the internal state of an object. This way of seeing things solves also the problem og encapsulation violation for queries. In fact, query criteria (HQL, JDOQL, JPQL) should be regarded as applied to the snapshot and not the object. (OK, you have in-memory queries too, I know, but we live in an imperfect world, but I am sure we can survive even with this painful, somehow distorted reality) Guido

What I see issues with is the idea that the object and the database are the same thing. That is, if you look at the object, you are looking at the database, if you update the object you update the database. If you take that assumption away and think about objects as snapshots of data, a lot of the complexities disappear.

I prefer to see the other way around.
Persistent image is a snapshot of the internal state of an object.
This way of seeing things solves also the problem og encapsulation violation for queries.
In fact, query criteria (HQL, JDOQL, JPQL) should be regarded as applied to the snapshot and not the object.
(OK, you have in-memory queries too, I know, but we live in an imperfect world, but I am sure we can survive even with this painful, somehow distorted reality)

Guido

It's an equally valid way of looking at things but my experience tells me it's a tough row to sow. It's fine as long as you have one session with one client at a time. But the whole point of a tiered architecture is to improve scalability. So you can call your current session reality but so will the other clients. What happens if they don't agree? Then you need to synchronize the sessions. Technically possible but not easy and definitely not foolproof. The one thing that everyone can agree on is the current state of the database. Mainly because it is a single point of truth. In the end you are really just fooling yourself if you think the objects are more important than what it saved in the database. If the hibernate session crashes, no one will see whatever it was that you did, unless... You saved it to the database. There are other ways to structure your persistence such as data grids but Hibernate is not one of them. It's inherently tied to the DBMS. Every single challenge I have faced working with Hibernate is a result of Hibernate trying to avoid facing this truth. It's stuck in a time when objects were expensive. Contemporary objects are cheap, convenient, and disposable.

It's fine as long as you have one session with one client at a time. But the whole point of a tiered architecture is to improve scalability. So you can call your current session reality but so will the other clients. What happens if they don't agree? Then you need to synchronize the sessions. Technically possible but not easy and definitely not foolproof. The one thing that everyone can agree on is the current state of the database. Mainly because it is a single point of truth.

It's been a long time since modern DBMS's contained a "single point of truth". The only time that ever happens is when nobody is using the database, or you use serializable isolation for everything. The multisession problem you describe is intrinsic to concurrent DB access.

It's fine as long as you have one session with one client at a time. But the whole point of a tiered architecture is to improve scalability. So you can call your current session reality but so will the other clients. What happens if they don't agree? Then you need to synchronize the sessions. Technically possible but not easy and definitely not foolproof. The one thing that everyone can agree on is the current state of the database. Mainly because it is a single point of truth.

It's been a long time since modern DBMS's contained a "single point of truth". The only time that ever happens is when nobody is using the database, or you use serializable isolation for everything. The multisession problem you describe is intrinsic to concurrent DB access.

How do you figure? What DBMS allows multiple committed states for a single record at one time?

What I see issues with is the idea that the object and the database are the same thing. That is, if you look at the object, you are looking at the database, if you update the object you update the database. If you take that assumption away and think about objects as snapshots of data, a lot of the complexities disappear.

I prefer to see the other way around.
Persistent image is a snapshot of the internal state of an object.
This way of seeing things solves also the problem og encapsulation violation for queries.
In fact, query criteria (HQL, JDOQL, JPQL) should be regarded as applied to the snapshot and not the object.
(OK, you have in-memory queries too, I know, but we live in an imperfect world, but I am sure we can survive even with this painful, somehow distorted reality)

Guido

It's an equally valid way of looking at things but my experience tells me it's a tough row to sow.

It's fine as long as you have one session with one client at a time. But the whole point of a tiered architecture is to improve scalability. So you can call your current session reality but so will the other clients. What happens if they don't agree? Then you need to synchronize the sessions. Technically possible but not easy and definitely not foolproof. The one thing that everyone can agree on is the current state of the database. Mainly because it is a single point of truth.

In the end you are really just fooling yourself if you think the objects are more important than what it saved in the database. If the hibernate session crashes, no one will see whatever it was that you did, unless... You saved it to the database. There are other ways to structure your persistence such as data grids but Hibernate is not one of them. It's inherently tied to the DBMS.

Every single challenge I have faced working with Hibernate is a result of Hibernate trying to avoid facing this truth. It's stuck in a time when objects were expensive. Contemporary objects are cheap, convenient, and disposable.

Try to separate logical view of things from other aspects. Objects are data+behaviour, you know, so persistent state cannot be THE object. It has no behaviour. To deal with the problem you pose you have to put on the table the fact that an object can be replicated, either in the same VM but different sessions, persistence manager or entity manager, or different VM. On this topic I found rather useful all the papers around the Arjuna system of Newcastle university (more than 10 years ago). And I have to say that I disagree with your criticism to the hibernate, or ORM in general I guess, point of view. Their job is to limit the well-known impedence mismatch between object model and relational model. But maybe I might miss your point. Guido

I prefer to see the other way around.
Persistent image is a snapshot of the internal state of an object.
This way of seeing things solves also the problem og encapsulation violation for queries.
In fact, query criteria (HQL, JDOQL, JPQL) should be regarded as applied to the snapshot and not the object.
(OK, you have in-memory queries too, I know, but we live in an imperfect world, but I am sure we can survive even with this painful, somehow distorted reality)

Guido

I appreciate your view from a theoretical point of view; however my personal experience has taken me to draw the following conclusions:

• Object are a representation of the underlying data and not the other way around: this because data very often survives the code. Additionally, ORM specs like JPA are very limited as to describing all the features of the underlying schema (Hibernate is much more complete);
• Many applications require external systems to share the database your ORM is managing - and no, these external systems cannot be reworked to call a web service instead; in this case deferred writes are are a no-go and lead to having the in-memory object being just identical to its present in-DB representation.
Alessandro

Persistent image is a snapshot of the internal state of an object.

I like your way to see. But then, once I get objects, I tend to write things like "for" loop. It leads to typical performance bottleneck, and concurrency issues due to dirty reads. Thus, in fact, there're many don'ts when you use ORM tools, which are natural when you write your code. So, I need a decent knowledge of RDBMS to make it work. That's why, in practice, I have to see the other way around. Still, I'm wondering if there's anything like a compiler for object persistence, which might be beyond programming language, so that I could take the view I like.

1300 lines of shit. I don't get you people and your frameworks, re-inventing the wheel then claiming it's less LoC and no dependencies. You know what? I think you convinced me, I'm going to scratch my project and replace Hibernate with this, even though it's only capable of 1% of the functionality.

I actually tried it with a simple app 4 tables with some associations with caching ( terracota and ehcache ). Eclipse Link (Toplink) worked fine. Hibernate worked fine . The caching with things does not know what it is. The Mapping is very basic, you better not have a FK. The worse is it is advertised like a champ.

1300 lines of shit. I don't get you people and your frameworks, re-inventing the wheel then claiming it's less LoC and no dependencies. You know what? I think you convinced me, I'm going to scratch my project and replace Hibernate with this, even though it's only capable of 1% of the functionality.

If your happy with your current ORM solution, go with it. But don't call my code "shit" without really taking a look at it. I've been using Hibernate for years. And I still would if it would be productive approach for our projects. I didn't write my own solution just for fun. I did it because I needed it. I needed SIMPLE ORM.

I use IBatis and I am happy with it. It is simple and powerful.

Mapping has never been a problem with Hibernate. Tight coupling with Spring is just not a good practice. Can you please provide what Kauklahti resolves that other ORMs did not.

Mapping has never been a problem with Hibernate.
Tight coupling with Spring is just not a good practice.
Can you please provide what Kauklahti resolves that other ORMs did not.

First of all, the framework is not directly coupled with Spring. There are no class references in Kauklahti code to Spring (except tests). But it is easiest to execute SQL (any JDBC SQL really) with JdbcTemplate. The following is from Kauklahti FAQ: You might want to consider using Kauklahti, if you feel your current ORM solution:

• is hard to configure
• depends on too many external libraries with exact versions
• requires mapping annotations that mess your code
• requires xml that is error-prone and tedious
• lacks possiblility to change mapping hierarcies dynamically
• generates too many single queries
• causes lot of performance bottle necks
• requires lot of tuning after bad configurations
• gives you lazy fetching and library specific collections when you don't need it
• offers all kinds of features you don't need and you would appreciate simpler solution

You might want to consider using Kauklahti, if you feel that SQL with JDBC:

• causes long methods with high complexity
• is more or less error-prone
• is tedious with hundreds of select/insert/update/delete statements

I have checked out the code. Looks very interesting. JdbcTemplate is pretty neat way to execute queries and I agree with you that caching trouble makes hibernate a bit scary. Will comment further after going through the tests and stuff. Thanks for sharing!

Why not add a db introspector feature that can generate the dto classes? That feature might make the adoption much easier. Also it will help people to test the lib against some existing apps. I have a few that curently daos through JPA+HibernateImpl that I can throw this lib against.

Why not add a db introspector feature that can generate the dto classes? That feature might make the adoption much easier. Also it will help people to test the lib against some existing apps. I have a few that curently daos through JPA+HibernateImpl that I can throw this lib against.

If you need table to JavaBean generator, you could probably use existing ORM tools. Kauklahti is about JavaBeans and Collections (just get rid of that xml/annotations). Some kind of GUI could be handy to get started. But if you need to map properties to columns with different names, you could as well write directly Java code with Table-object (instead of typing this in GUI). I mean that API is very simple to use also without generators, the basic idea is to avoid all bells and whistles, just to solve JavaBean to SQL problem in simplest possible way. Anyway, thanks for the idea. I will think about this.

iBatis is simple and still gives you handle to do optimization without all heavy duty crap of hibernate. Hibernate to iBatis is like Webloigc to Tomcat.

I'd consider a different name for this project. Nobody's going to be able to remember how to type it. I don't even know how to pronounce it. It'll be difficult to google for.

In spite of modern JPA implementations, object-relational mapping is still "the Vietnam of our industry"

Only if you're so stupid that you hand-write these mappings. Hibernate is a wonderful, stable, robust and fast framework that deserves a lot more respect than it gets. I took a good look at Kauklahti and it appears to cover what I need. FOR TOY STUFF. Get real.

In spite of modern JPA implementations, object-relational mapping is still "the Vietnam of our industry"

Only if you're so stupid that you hand-write these mappings.

Hibernate is a wonderful, stable, robust and fast framework that deserves a lot more respect than it gets.

I took a good look at Kauklahti and it appears to cover what I need. FOR TOY STUFF.

Get real.

han theman, how long have you been coding with Hibernate? How many projects with how many table mappings? Do you work with it daily? We are not toying with our framework, we are keeping a real project in schedule.

I took a good look at Kauklahti and it appears to cover what I need.

I do not know if I should be wasting a few minutes to explain what research and innovation is. I guess that - from your point of view - Hibernate has always existed and nobody tried to bash that out when it first hit the Java community; but I am sure you will not understand. The most important point is your faulty language and the arrogant stance you have shown here. If there is an ignorant that's - again - you. For me this message would be enough to ask the administrator of TSS to ban your account. P.S.: I do not like ORM in general and iBatis IMHO does a much better job at addressing the object-relational mapping issue.

If there is a bastard here, that's you; if there is an ignorant that's - again - you.

For me this message would be enough to ask the administrator of TSS to ban your account.

LOL.

Another lightweight ORM is Ujorm: http://ujoframework.org/orm/

Editor: For the record, I've done some very minor editing on a couple of the posts to remove potentially offensive language. I apologize for that, and ask that we keep the discussion civil. Thanks.

Y'know, there was a time when Hibernate was just a couple of thousands of lines of code. And then people started using it. And they asked for more features. And so it grew. But of course it's unlikely that this will ever happen to Kauklahti.

Y'know, there was a time when Hibernate was just a couple of thousands of lines of code. And then people started using it. And they asked for more features. And so it grew.

But of course it's unlikely that this will ever happen to Kauklahti.

Gavin, I get your point. Kauklahti will grow when I get more ideas. Although I try to keep it small as possible, limited to solving one problem. I actually did not want to attack against Hibernate. It has been a remarkable tool in Java development. I just needed a slightly provocative title to get the attention. But I wish there would have been "Hibernate Lite", or some other really simple tool with an API I like. There probably is one among the thousands of ORM tools, but I just could not find one. And when I started thinking about it, coding a framework that translates "Objects to SQL" and "ResultSet to Objects" was actually ridiculously easy, even with a simple join support. So I did it myself. The point in this post is that we need simple tools for simple needs. If you want caches, sessions, lazy fetching and the likes, a full-blown ORM makes sense. If your architecture has all the other blocks in place and you just need a simple SQL-generator, then tools like Kauklahti will probably give you less gray hair. Use whatever works. Sometimes building it yourself might actually make sense. And respect people's work, whatever it is. Be nice :)

have you not discovered iBatis yet?

have you not discovered iBatis yet?

IBatis is a full-blown ORM. XML/annotations and writing mapped SQL-statements is not what I need. Kauklahti API is totally different.

If your needs are simple then this seems like it could be the way to go. Although Hibernate can do simple too. On the other hand, if your needs are more complex, then you application lines of code will expand while with Hibernate (or like ORMs) .. you just use the API.

Y'know, there was a time when Hibernate was just a couple of thousands of lines of code. And then people started using it. And they asked for more features. And so it grew.

But of course it's unlikely that this will ever happen to Kauklahti.

Yeah. It is so "funny". First it was "Hibernate doesn't do this. I can use it." So you added it. Not it is "Hibernate does too much, i can't use it." LOL. Well the good thing is that Hibernate pretty much can do as little or as much as you need. Want to just treat tables as objects? It can. Want to use SQL? It can.

Y'know, there was a time when Hibernate was just a couple of thousands of lines of code. And then people started using it. And they asked for more features. And so it grew.

But of course it's unlikely that this will ever happen to Kauklahti.

Yeah. It is so "funny". First it was "Hibernate doesn't do this. I can use it." So you added it. Not it is "Hibernate does too much, i can't use it." LOL. Well the good thing is that Hibernate pretty much can do as little or as much as you need.

Want to just treat tables as objects? It can. Want to use SQL? It can.

should have been "can't use it".

Y'know, there was a time when Hibernate was just a couple of thousands of lines of code. And then people started using it. And they asked for more features. And so it grew.

But of course it's unlikely that this will ever happen to Kauklahti.

Yeah. It is so "funny". First it was "Hibernate doesn't do this. I can use it." So you added it. Not it is "Hibernate does too much, i can't use it." LOL. Well the good thing is that Hibernate pretty much can do as little or as much as you need.

Want to just treat tables as objects? It can. Want to use SQL? It can.

should have been "can't use it".

Editing, TSS. This is absurd that we cannot edit posts. Is it not time to change the back in to perhaps, vbulletin?

Often I complain there's yet another ORM in java space, but it's better than the alternative of not having any choice or very few choices. It might not have generated as many flames if the hype was toned down. peter

I find it interesting how many new ORM solutions pop up every week. Clearly the available ORM solutions don't meet everyone's needs. But that doesn't mean we need to keep creating more. This has been one of the biggest problems with persistence (and many other concerns) in Java for far too long. I do think the time has come to stop re-invinting the wheel. I'm not saying that Kauklahti is a bad framework... It might be great. But as a community, we need to stop doing this sort of thing. To put my two cents in on the ORM wars: I have used hibernate and iBatis enough to consider myself fairly proficient at them (though hardly an expert). Here's my take: Hibernate: Very good, but because of its steep learning curve and the lack of initiative for coders to truly learn the framework, we far too often see code that just works badly. Basically, on a project using hibernate, someone who really knows how it works needs to be heavily involved. Two recommendations here: 1) Turn off caching altogether until you're at the end of the project and then VERY carefully add it in to improve performance. Much of the confusion in hibernate is just confusion over how caching works. 2) Pay for Java Persistence with Hibernate and read it... all of it (but ignore the JPA stuff at first). Then experiment until you truly understand what you're doing, don't just figure out how to make your code work. Understand HOW it works. iBatis: People think of this as a rival to hibernate, but it's not. hibernate is apples, iBatis is oranges. For one thing, iBatis is NOT ORM. It's a query-mapping framework. iBatis is perfect for complex or legacy database structures and applications where the concepts involved don't really break down into true domain objects. It also makes it easier to do translation of the results of extremely complex queries into objects. There is some overlap with hibernate, but more often than not, one is clearly a better candidate for what your system needs to do. Best of all: it has almost NO learning curve. If you don't have any hibernate experience and don't have the time (or the inclination) to gain it, iBatis is a great choice for taking away some of the tedium (but not the flexibility) of direct JDBC. Just be aware that hibernate (when you know what you're doing) can offer quite a bit of coding and maintenance efficiency that iBatis can ever achieve (as well as a certain amount of portability that I honestly think is a little overrated...)

I find it interesting how many new ORM solutions pop up every week. Clearly the available ORM solutions don't meet everyone's needs. But that doesn't mean we need to keep creating more. This has been one of the biggest problems with persistence (and many other concerns) in Java for far too long.

I do think the time has come to stop re-invinting the wheel. I'm not saying that Kauklahti is a bad framework... It might be great. But as a community, we need to stop doing this sort of thing.

To put my two cents in on the ORM wars:

I have used hibernate and iBatis enough to consider myself fairly proficient at them (though hardly an expert). Here's my take:

Hibernate: Very good, but because of its steep learning curve and the lack of initiative for coders to truly learn the framework, we far too often see code that just works badly. Basically, on a project using hibernate, someone who really knows how it works needs to be heavily involved. Two recommendations here: 1) Turn off caching altogether until you're at the end of the project and then VERY carefully add it in to improve performance. Much of the confusion in hibernate is just confusion over how caching works. 2) Pay for Java Persistence with Hibernate and read it... all of it (but ignore the JPA stuff at first). Then experiment until you truly understand what you're doing, don't just figure out how to make your code work. Understand HOW it works.

iBatis: People think of this as a rival to hibernate, but it's not. hibernate is apples, iBatis is oranges. For one thing, iBatis is NOT ORM. It's a query-mapping framework. iBatis is perfect for complex or legacy database structures and applications where the concepts involved don't really break down into true domain objects. It also makes it easier to do translation of the results of extremely complex queries into objects. There is some overlap with hibernate, but more often than not, one is clearly a better candidate for what your system needs to do. Best of all: it has almost NO learning curve. If you don't have any hibernate experience and don't have the time (or the inclination) to gain it, iBatis is a great choice for taking away some of the tedium (but not the flexibility) of direct JDBC. Just be aware that hibernate (when you know what you're doing) can offer quite a bit of coding and maintenance efficiency that iBatis can ever achieve (as well as a certain amount of portability that I honestly think is a little overrated...)

I think you use the expression "ORM war" and consider only hibernate and iBatis as the only contestants just because of your familiarity with only these two tools. Anyway, world is a little bit larger and some of the drawbacks you find in your candidates might not be present in others. But, I agree with you, everyone should understand what he/she is using first and how it works. I have always tried to have uniform management of domain objects since the beginning of my life with Java (jdk 1.0.2), so I have always found the query language being the real Achille's heel of any iBatis-like solution. When I first used Java Relational Binding with its OQL it looked like a real revolution. The big jump forward came (for me) with the advent of JDO. I have been using Kodo for several years with great satisfaction: simple API, really really good implementation and almost flat learning curve. Nowadays you can persist/retrieve objects in a uniform and consistent way across different backend technologies (RDBMS, OODBMS, LDAP, GAE, ....). So, in the end, is there room for other persistence frameworks ? Maybe yes, who knows. But a gap filling analysis might help to understand the purpose of a new proposal. Guido

I have used iBATIS for many business applications, and I have always been happy with it, especially with the iBATOR tool that generates classes from tables. I totally agree with Aaron Craven for the comparison between Hibernate and iBATIS. And I also agree that people should stop creating new ORM projects... Thanks for the discussion, it's always interesting to hear what other people think Gilles S

I find it interesting how many new ORM solutions pop up every week. Clearly the available ORM solutions don't meet everyone's needs. But that doesn't mean we need to keep creating more. This has been one of the biggest problems with persistence (and many other concerns) in Java for far too long.

I do think the time has come to stop re-invinting the wheel. I'm not saying that Kauklahti is a bad framework... It might be great. But as a community, we need to stop doing this sort of thing.

To put my two cents in on the ORM wars:

I have used hibernate and iBatis enough to consider myself fairly proficient at them (though hardly an expert). Here's my take:

Hibernate: Very good, but because of its steep learning curve and the lack of initiative for coders to truly learn the framework, we far too often see code that just works badly. Basically, on a project using hibernate, someone who really knows how it works needs to be heavily involved. Two recommendations here: 1) Turn off caching altogether until you're at the end of the project and then VERY carefully add it in to improve performance. Much of the confusion in hibernate is just confusion over how caching works. 2) Pay for Java Persistence with Hibernate and read it... all of it (but ignore the JPA stuff at first). Then experiment until you truly understand what you're doing, don't just figure out how to make your code work. Understand HOW it works.

iBatis: People think of this as a rival to hibernate, but it's not. hibernate is apples, iBatis is oranges. For one thing, iBatis is NOT ORM. It's a query-mapping framework. iBatis is perfect for complex or legacy database structures and applications where the concepts involved don't really break down into true domain objects. It also makes it easier to do translation of the results of extremely complex queries into objects. There is some overlap with hibernate, but more often than not, one is clearly a better candidate for what your system needs to do. Best of all: it has almost NO learning curve. If you don't have any hibernate experience and don't have the time (or the inclination) to gain it, iBatis is a great choice for taking away some of the tedium (but not the flexibility) of direct JDBC. Just be aware that hibernate (when you know what you're doing) can offer quite a bit of coding and maintenance efficiency that iBatis can ever achieve (as well as a certain amount of portability that I honestly think is a little overrated...)

I think you use the expression "ORM war" and consider only hibernate and iBatis as the only contestants just because of your familiarity with only these two tools.
Anyway, world is a little bit larger and some of the drawbacks you find in your candidates might not be present in others.
But, I agree with you, everyone should understand what he/she is using first and how it works.
I have always tried to have uniform management of domain objects since the beginning of my life with Java (jdk 1.0.2), so I have always found the query language
being the real Achille's heel of any iBatis-like solution.
When I first used Java Relational Binding with its OQL it looked like a real revolution.
The big jump forward came (for me) with the advent of JDO.
I have been using Kodo for several years with great satisfaction: simple API, really really good implementation and almost flat learning curve.
Nowadays you can persist/retrieve objects in a uniform and consistent way across different backend technologies (RDBMS, OODBMS, LDAP, GAE, ....).
So, in the end, is there room for other persistence frameworks ?
Maybe yes, who knows.
But a gap filling analysis might help to understand the purpose of a new proposal.


Guido

Just to clarify: You are correct that I only present my opinions on hibernate and iBatis in the ORM wars because they are the only frameworks I have considerable experience with. I did not in any way mean to imply they are the only options out there (though I would dare to say they are probably the most well-known and popular choices). Indeed, that's part of my beef here: people keep creating more to the point that there are far too many options out there.

Just to clarify: You are correct that I only present my opinions on hibernate and iBatis in the ORM wars

I've never understood why it has to be a "war" :-) Software is there to solve a problem. Problems are often very different. There is no one single solution, hence multiple alternatives come up. It is often desirable to have one "solution" that solves many problems, hence collaboration is better but not always possible due to the difference in the problem space. Using number of lines of code as a way of judging the "solution" simplicity and completeness is nonsensical; all that says is that it tries to solve one specific simple problem. and. nothing. else.

people keep creating more to the point that there are far too many options out there.

Well it all comes down to 2 things 1. Does some tool/framework already do what they want to do, at least in part ? 2. Do people want to collaborate with existing solutions to provide what they need ? The answer to the first question is almost always yes (certainly for Java persistence). The answer to the second question is almost always no, sadly. People usually aren't interested in taking someone else's work (no matter how good it is) and adapting it, instead liking reinvention of said wheel, and saying oh well that didn't do what we wanted, forgetting to mention that they didn't even consider talking to the developers of existing software to explore some possibilities. The other point is, any new software should answer a simple question ... what does it offer that an existing solution doesn't solve? If it doesn't provide such information in its announcement then it, almost always, is not worth looking at. In my case we started DataNucleus, originally in 2003, when there was an existing solution of the form we required but, when approached by us, the authors of that software weren't interested in collaborations so we went our own way and developed a new tool. We accept collaboration from any group, hence why Google developed their own plugin for DataNucleus, rather than writing their own JDO/JPA implementation. In our case also, we look at a much larger problem space (RDBMS, ODBMS, XML, Excel, ODF, LDAP, JSON, BigTable, Amazon S3, HBase) than the two examples you've provided, hence our reason to exist is clear :-) --Andy (DataNucleus)

I find it interesting how many new ORM solutions pop up every week. Clearly the available ORM solutions don't meet everyone's needs. But that doesn't mean we need to keep creating more. This has been one of the biggest problems with persistence (and many other concerns) in Java for far too long.

I do think the time has come to stop re-invinting the wheel. I'm not saying that Kauklahti is a bad framework... It might be great. But as a community, we need to stop doing this sort of thing.

To put my two cents in on the ORM wars:

I have used hibernate and iBatis enough to consider myself fairly proficient at them (though hardly an expert). Here's my take:

Hibernate: Very good, but because of its steep learning curve and the lack of initiative for coders to truly learn the framework, we far too often see code that just works badly. Basically, on a project using hibernate, someone who really knows how it works needs to be heavily involved. Two recommendations here: 1) Turn off caching altogether until you're at the end of the project and then VERY carefully add it in to improve performance. Much of the confusion in hibernate is just confusion over how caching works. 2) Pay for Java Persistence with Hibernate and read it... all of it (but ignore the JPA stuff at first). Then experiment until you truly understand what you're doing, don't just figure out how to make your code work. Understand HOW it works.

iBatis: People think of this as a rival to hibernate, but it's not. hibernate is apples, iBatis is oranges. For one thing, iBatis is NOT ORM. It's a query-mapping framework. iBatis is perfect for complex or legacy database structures and applications where the concepts involved don't really break down into true domain objects. It also makes it easier to do translation of the results of extremely complex queries into objects. There is some overlap with hibernate, but more often than not, one is clearly a better candidate for what your system needs to do. Best of all: it has almost NO learning curve. If you don't have any hibernate experience and don't have the time (or the inclination) to gain it, iBatis is a great choice for taking away some of the tedium (but not the flexibility) of direct JDBC. Just be aware that hibernate (when you know what you're doing) can offer quite a bit of coding and maintenance efficiency that iBatis can ever achieve (as well as a certain amount of portability that I honestly think is a little overrated...)

Totally agree with the analysis about Hibernate. Even people using it for some time don't know all the quirks of Hibernate. It is very quick to define complex things in Hibernate but you spend 50% of your time debugging the consequences due to caching, mapping definitions and lazy instantiation. For example, to get around the lazy instantiation one ends up using OpenSessionInViewFilter. What a mistake. The consequences are subtle and will cost you dearly if you don't know what you are doing.

Totally agree with the analysis about Hibernate. Even people using it for some time don't know all the quirks of Hibernate. It is very quick to define complex things in Hibernate but you spend 50% of your time debugging the consequences due to caching

What I have determined is that the Critieria API (which I like pretty well) is incompatible with caching in hibernate (including the first level cache.) Depending on which order you make you queries, your results can be very different unless you trash the session before each lookup.

There are 100,000's of people who have bypassed ORM technology completely by using an Object Database. I think it would do (more) people a lot of good to take a look at the easiest alternative. Lots of people have already figured this out. Since 2005 the db4o team ( now at Versant) have been delivering ORM-less database technology and in only 4 years have grown a registered community in excess of 70K people and have deployments in systems doing everything from SCADA - controlling major train lines around the world to communications systems in our major airports in the U.S. and network management in the largest telco's in the world to simple games deployed on Android. The parent company Versant has an object database which has matured over a decade and is deployed in some of the largest OLTP systems in the world. The technology is dynamic n-cluster, fully distributed object graphs, parallel query, fault tolerant, etc ... being used by 10 out of 10 top telecommunications companies in the world. These technologies are especially useful if you are building green field. However, none of us work in a vacuum, so there are replication technologies too which allow you to sync with other systems ... for example db4o has it's dRS which uses Hibernate to replicate to any relational system. At Versant we say, our technology is used to build the applications that "define your business", not necessarily the applications which "run your business". People build companies on the back of our product ( doing the hard stuff ) and they run their companies on the products on the back of RDBMS products ( the simpler stuff ). Albiet, the simpler stuff is where the volume is .... so something like Kauklahti or Hibernate makes sense, but when you're the rocket scientist, you really ought to be bypassing this ORM issue all together. -Robert Versant Corp Db4Objects

Sounds great. So how much is the licence cost?

Depends on which product. ....these are estimates not exact numbers. db4o is free open source GPL. Or it's commercial OEM based on volume. OEM range is from 1K for single client/server to pennies for large volume and average cost based on the deals we've done to date has been under $100. On the Versant side, again depends on volume. A single Enterprise License with all the bells and whistles with no volume discounts or negotiations is somewhere around 20K. At volume we've done deals as low as $25 per copy. Average price of a license based on the deals we've done to date is probably around 5K. We also just last week released a product for the CLR. I think pricing there is also in the 5K range. Hope this helps ... -Robert The db4o team Versant Corp

"Object-Relational mapping is the Vietnam of our industry"
The war you cannot win.

For years people have tried to get things right using the wrong approach. Sometimes a battle was won but loosing the war is inevitable. Hibernate has turned into a monster that can hardly be tamed. And so will do other solutions that take the same approach. Jeff Atwood makes point in http://www.codinghorror.com/blog/archives/000621.html: “Personally, I think the only workable solution to the ORM problem is to pick one or the other: either abandon relational databases, or abandon objects. If you take the O or the R out of the equation, you no longer have a mapping problem.“ We have skipped the 'O' and - believe it or not - it works. Lighter, faster, simpler -> smarter. See http://incubator.apache.org/empire-db

"Personally, I think the only workable solution to the ORM problem is to pick one or the other: either abandon relational databases, or abandon objects. If you take the O or the R out of the equation, you no longer have a mapping problem"

Concise way of putting it. Indeed, we at Versant have choosen the 'O', so those who wish to use Objects can rely on us to loose the mapping problem. -Robert The db4o team Versant Corp

JDO came and saw and conquered all of these issues years ago: - avoiding writing to a proprietary ORM eg Hibernate - avoiding dependencies on too many other frameworks - avoiding writing to an interface that is effectively only an ORM which mandates an RDBMS datastore but instead, one that allows the flexibility to deploy to number of different datastore technologies: store to RDBMS, Object Databases (eg db4o), Google Big App tables, LDAP even EXCEL (the open source http://www.datanucleus.org JDO implementation provides all these). - avoiding modeling and coding limitations due to special requirements of the ORM If your app is so popular that it needs to scale up fast (and who wouldn't want that?) it's good to know you can switch your JDO persisted application to other options (eg., Google Big App/Cloud) without rewriting it. The guys who nutted out the JDO standard many years ago were some of the smartest Java dudes on the planet. It's interesting that it's only in recent years that a ground swell of developers are starting to look for solutions to issues that those guys foresore and solved many years ago. I guess that's a testament to their credentials as forward thinkers. I guess at the time the only datastore anyone would ever consider storing their data in was an RDBMS but we live in a rapidly changing world. JDO developers are now able to appreciate the benefits of JDO's 'future proof' attributes and the advantage of creating a standard that was more than 'just an ORM'. The JDO designers had the insight to abstract the concept of the very underlying datastore itself leaving JDO apps in the enviable position of being easily ported to more recently mainstream storage technologies such as object databases and specific cloud platforms. The other aspect which fellow JDO developers appreciate and take advantage of is complete modeling and coding freedom. The JDO persistence solution places no restrictions on your object modeling or coding because it's not implemented using the tired old, restrictive and inefficient proxy pattern + reflection techniques.

Does this framework support "Detached state"? If not, what is the equivalent way of doing it? Thanks.

Does this framework support "Detached state"? If not, what is the equivalent way of doing it? Thanks.

Yes Guido

The guys who nutted out the JDO standard many years ago were some of the smartest Java dudes on the planet. It's interesting that it's only in recent years that a ground swell of developers are starting to look for solutions to issues that those guys foresore and solved many years ago. I guess that's a testament to their credentials as forward thinkers

The main "guy" you are talking about is Craig Russell, spec lead for JDO. Craig is the original product manager of The Versant Object Database. The API which is the object lifecycle managment (OLM) abstraction layer at the top of JDO .... which frankly is also the OLM for JPA and Hibernate ( an area I will give Gavin credit for recognizing it's superiority long before the JPA folks ) ....... is 20 years old existing as The Versant Object Database API. It's funny, everyone in the world is a Versant Object Database expert and yet they don't even realize it. -Robert The db4o team Versant Corporation

In Vietnam, they call it "The American War of Aggression"... In other words, perspective is everything. The "complex configuration" you mention is only made more complex by the inline code that must be written to do the same thing. One commenter referred to using annotations for this configuration (although not by name). Annotations have been an ideal solution for domain table mapping for a long time (circa XDoclet). Just because Kauklahti doesn't use them doesn't mean it's better. One of the best features of Hibernate is database portability through query compilation to AST. That doesn't happen in 1300 lines of code. Kauklahti is certainly not going to replace Hibernate, but if it were to get close, it would be better not to have people like me having dismissed it years prior after reading such outlandish claims.

Hi folks Hibernate is much overrated. It's not the ORM of choice in every situation. For example in our company we develop an application for end users, a good old desktop application. For persistence we wanted to use a DB and so we took hibernate for ORM. What a misstake: In our application we have all the objects in memory, because we show them in all kind of GUIs, Undo/Redo stuff etc. Now, you can use Hibernate in two ways: One session or multiple sessions. In one session mode, the usage of the framework is easy: You allways get the same instance for the same db row. But the performance is very poor, hibernate does all kind of checks with all the objects in the session. So this is not an option. In multiple session mode you have the problem that for every new session you get new object instances for the same db row. This is a heavy burden for the application because now, the "ORM" which is so "transparent to the architecture" isn't very transparent or hidden. It hits you in the face in every layer of abstraction. The solution was to implement a special cache in the back of hibernate. Every session go to that cache and so we have multiple sessions with single object instances. But this code is a hack. Hibernate is not made for very case of persistence and that's ok. It doesn't have to be a silver bullet, that would be bad for the case it was really made: Server-side persistence. Greetings from the desktop front. (-: P.S. I happily will have a look at your library!

Yet another toy ORM; from too complex to too simple. A lot of useful database work is not simple table access, or simple key joins, that's just glorified persistence of object graphs. BTW, I hate bloated and obfuscating frameworks like Spring, and libraries which need Spring to work well, my pet hate being Spring Security. Major advantages of the XML based named queries and mappings, in iBastis, are, they can be pre-checked, to avoid live mapping errors, and both the SQL and mappings can be pre-optimised and pre-compiled, unlike reflection based ORMs like Kauklahti, so it runs fast, without the need for obfuscating IoC or Aspects. A large part of my work is data-mining like reports, which can require more complex SQL, with things like case, cast, group by, having, order by, SQL functions, most of the join types, and database specify query tweaks; try doing that efficiently, or at all, with toy ORMs like Kauklahti!

objec relational mapping is a vastly overrated 'solution' to an overstated 'problem'

like many others, i spent time tilting at this windmill, but came to the conclusion that most applications that use databases use them in a very simple manner that doesn't justify yet another framework

you know, sql ain't all that hard, and it is a standard (even if rdbms vendors don't know it); if all you are doing is some crud operations on a couple of simple tables, you don't need anything fancy

yes, that's an unfashionalbe view

 

orm in the most general case might just be an unsolvable problem, just as deadlock prevention in the most general case is unsolvable

like most complex problems, the best approach is to analyze the specifics and isolate the relevant subset of issues; if you really have a complex domain model and you really have to use some legacy database to support it, then maybe there's an orm solution that fits your needs, and maybe not

maybe you can revisit some of your architecture and design assumptions

 

and maybe you will have to write sql and stored procedures!

there are worse fates (anything.net)