To use ORM or not

[paul wheaton]

Years ago I got bit by using an object database: just pretend you have infinite memory. Everything is automatically persisted for you. That's it. And then as you use it, it starts getting more complicated. And don't forget, that after you compile everything, it has to re-process all of your classes. And it gets more complicated. And more complicated. It would seem that the marketing department took a lot of license. As the project progressed I came to the conclusion that we would be done a helluva lot faster if we had just used JDBC.
After ditching ODB, I went to a presentation on toplink. I have to admit, that it sounded mighty dreamy. All the benefits of the promises of ODB, but it is actually stored in a RDB. Oooooooo. Then I saw how you had to tell toplink about how to mash your objects into the relational database. So you still have to describe your persistance, but you do it with something other than java. So my conclusion after the presentation is that the value would be debatable. Later, I heard from other people that it's fine for like 90% of your stuff, but for anything interesting it starts getting complicated and regular JDBC is better. I've even heard of some projects where they think that if they stuck to JDBC to begin with, they would have been done sooner.
And now we have JDO on the horizon. I hear a lot of the same fantasy speak. But when you start asking questions, it sounds like the same issues.
And hibernate, and other ORM stuff.
And the "new CMP" for entity beans.
I dunno. It takes so long to learn this whole new way of doing things and you really don't get burned until you're 70% into the project and then it makes the last 30% of the project take 80% of the total time to get the project done. It seems like it would be wise to get all the facts straight first. To know about the shortcomings up front.
So all you guys that are into ORM: is the fantasy a reality, or are the not-so-obvious problems still there?

[Ken Robinson]

I am beginning to believe you may be right in thinking that the overhead is so much that you don't find a problem until you are too far into the project to change your mind.
We have spent time researching Hibernate and the developer who did most of the work went into it wanting to use it right away. We where given all the good points, but none of the bad points.
To me, lazy loading is just not needed, however it is built into Hibernate regardless of if you want it or not since any Collection, List or Set is replaced with a Hibernate specific class. This make distributing the Hibernate objects impossible (unless I'm missing something) for a feature that I think is bad design to begin with.
Basically, Hibernate will load child records when you first access them, regardless if you've asked for them to be loaded. If I load an Order bean, but do not ask for the OrderItem collection of that bean to also be loaded, it will still load if the OrderItem collection is accessed. It's just bad to not worry about when the actual load will occur in my opinion.
The main benifit of these tools is that many of the objects and basic data access is written for you. The drawback is that they each have their own systax/config files, query language, cost and limitations. I'm in favor of just having a generator the builds beans and DAOs for me.

[Brian McCallister]

I am pretty sure you can configure hibernate t not use lazy loading, and if you cannot - i know for a fact it is configurable in OJB.

[David O'Meara]

In this neck of the woods, we always use some sort of database abstraction on top of JDBC. Yes, you get the whole 'map your objects to something else rather than the database', but the benefit is that you do it one place. If your O-R mapping changes, you make that one change and all your objects work again. With raw JDBC, you'd need to visit each of your create, read, update and delete operations.
I haven't used JDO, Hibernate and many of the others but I have done a fair amount with Castor, TopLink and some proprietary database frameworks, and I'd still stick with them.
There is a learning curve moving to a ORM Tool, but that's the same with any tool. It'd be a mistake to use it without some knowledge how to use it before hand, and one person with a clue will save you all a large amount of time.
No tool I've used was ever perfect, and besides 'marketing creativity' one big problem is that programming to the tool is never the same as programming directly to the database. There will be many operation that you would have done directly on the database that aren't possible using a particular mapping tool.
I'm a pretty big fan of Castor. I don't love it and wouldn't suggest it for all occasions, but it does make mapping easier and it's saved me some trouble in the past. OQL (Object Query Language) is great and easy, but it isn't SQL and there are a large number of things you can do in SQL that either aren't possible or just don't exist. We've resorted on occasion to creating Database Views then mapping these as Objects to get around missing SQL features.
I don't mind TopLink either, but I can get over the way they try to pretend SQL is actually Java code. it looks like this...

Expression exp = new ExpressionBuilder(Person.class).get("name").equal(myName);

...to do "Select person from tblPerson where name='myName'"
I'm not sure I'm happy with Java pretending to be SQL, but it makes SQL 'in' operations trivial!

Expression exp = new ExpressionBuilder(Person.class).get("name").in(myVector);

I guess I'd conclude with saying these mapping tools won't save the Earth, but I'd rather make database changes in one place rather than have to search. I had a project where poor management had the database mappings changing 4-5 times a week, and I'd have sold my soul for Castor then.
Oh, and as a post-script: I've done retro-fitting with Castor too, and this may not be a good idea either. Once you have code that assumes data based on queries and those queries are no longer possible, you have to jump through a lot of hoops to get it working and the original solution looks better than the final one with SQL mashed into Castor.

[Gregg Bolinger]

My POV if it matters....
I think ORM is cool but I am not sure if any 1 tool has really hit the nail square. Like David said, no tool is perfect. But I would say they are further from perfect than what I would even like.
And has been mentioned, the learning curve to use any of them is right in your face. And with any technology, the project should really warrent it. I think ORM should be used for DB heavy weighted apps. Im talking, everytime you click something the DB is being accessed, read, written to, whatever. The extra time it takes to :
a. Learn the tool
b. setup all the config for the tool
c. implement the tool
I could have whipped out a few JavaBeans with some Database code. Heck, I could use Jenny.
The point is the project should warrent the overhead of implementing the ORM tool. You shouldn't use it just because it's available.

[Rick Hightower]

I've used and written OR mapping tools.
I prefer to use ORM tools than write JDBC code from scratch.
It is not that the JDBC code is hard. It is just that it is sooo monotonous (sp?), and error prone.

I use to be a big fan of EJB CMP CMR, but now I really like Hibernate.
Lazy loading is configurable with Hiberante.

[Ken Robinson]

Originally posted by Brian McCallister:
I am pretty sure you can configure hibernate t not use lazy loading, and if you cannot - i know for a fact it is configurable in OJB.

Regardless of if Lazy Init is enabled or not, does not Hibernate provide it's own implementation of the List, Set and Collection classes? The fact that the implementation of these Interfaces are Hibernate specific, does that not limit the ability to make any of these beans practical in a distributed environment?
If I have a Stateless Sesssion Bean I can call a Remote Interface and I get a bean created by Hibernate that contains some sort of Collection, my client has to have either the entire Hibernate jar file or a subset of it just for the Hibernate Collections. Also, Lazy Init is not even an option as this point since the actual bean has not idea that is now 'remote' and 'outside of Hibernate', thus the underlying Connection to it's persistent data just does not exist on the client.
I like what I've seen of Hibernate so far, but given that my current project requires that about 15% of our functionality is company specific, not just app, several of our objects will be Stateless Session EJBs.
We plan on trying to create a seperate jar file containing only the Hibernate Collections for all clients and forcing an init of any 'child' tables (if I ask for an Order, I get the Order with OrderBean collection populated) or some other method of populating children as explicitly requested.
I just do not see where Lazy Init is even practical. When will the developer not know exactly what level of data is required? My personal view is that using Lazy Init is just bad design, and Hibernate has some cost and limitations associated with it.
[ January 05, 2004: Message edited by: Kenneth Robinson ]

[Renat Zubairov]

Originally posted by Kenneth Robinson:

If I have a Stateless Sesssion Bean I can call a Remote Interface and I get a bean created by Hibernate that contains some sort of Collection, my client has to have either the entire Hibernate jar file or a subset of it just for the Hibernate Collections. Also, Lazy Init is not even an option as this point since the actual bean has not idea that is now 'remote' and 'outside of Hibernate', thus the underlying Connection to it's persistent data just does not exist on the client.
[ January 05, 2004: Message edited by: Kenneth Robinson ]

In Hibernate it's possible to detach object or attach it back and in this case you don't have a dependency on connection anymore.
You can read about it here:
http://www.hibernate.org/21.html#A11
.
[ January 08, 2004: Message edited by: Renat Zubairov ]

[Ken Robinson]

Originally posted by Renat Zubairov:

In Hibernate it's possible to detach object or attach it back and in this case you don't have a dependency on connection anymore.
You can read about it here:
http://www.hibernate.org/21.html#A11

Ooooohhhh, Gold Star.
I have to admit that I was not tasked with evaluating Hibernate and have not yet had the time I want to devote to becoming as informed as I will need to be yet. I was told this was not possible and I thank you very much for pointing this out.
Usually I am not easy to convince to use a 'new' tool before it is proven, but I have to say Hibernate so far appears to be top notch.

[Ken Robinson]

Originally posted by Renat Zubairov:

In Hibernate it's possible to detach object or attach it back and in this case you don't have a dependency on connection anymore.
You can read about it here:
http://www.hibernate.org/21.html#A11

Ok, I've given this much thought and I still need convincing, so here are a few questions:
-In a distributed environment, does the client need to know about Hibernate (have the Hibernate jar or other jar) to use the beans created by Hibernate to represent the persistent data?
-Say a SLSB is called and it creates, through Hibernate, an OrderBean. It sends that OrderBean to the remote client. That OrderBean has a member called orderItems that is a Collection. When created, the orderItems Collection was not initialized. What can/can't the client do with that Collection on the Client side?
Most of these questions have to do with the fact that I do not know what Hibernate does with the bean when it is modified through CGLib. I know that Hibernate implements their own Collections and those are placed into the bean as the implementation of the defined Collection interface. This has to effect the client somehow as a concrete implementation of the Collection is required on the client end, it is going to know that is was a Hibernate Collection and even if the client has that class available, what classes does it need (Hibernate Session) as the Collection may be uninitialized?

[Renat Zubairov]

Originally posted by Kenneth Robinson:

Ok, I've given this much thought and I still need convincing, so here are a few questions:
-In a distributed environment, does the client need to know about Hibernate (have the Hibernate jar or other jar) to use the beans created by Hibernate to represent the persistent data?
-Say a SLSB is called and it creates, through Hibernate, an OrderBean. It sends that OrderBean to the remote client. That OrderBean has a member called orderItems that is a Collection. When created, the orderItems Collection was not initialized. What can/can't the client do with that Collection on the Client side?
Most of these questions have to do with the fact that I do not know what Hibernate does with the bean when it is modified through CGLib. I know that Hibernate implements their own Collections and those are placed into the bean as the implementation of the defined Collection interface. This has to effect the client somehow as a concrete implementation of the Collection is required on the client end, it is going to know that is was a Hibernate Collection and even if the client has that class available, what classes does it need (Hibernate Session) as the Collection may be uninitialized?

Actually I haven't used this feature in such distributed envromtent but I think that first question is true. You can see here:
http://www.hibernate.org/124.html
And here
http://www.hibernate.org/161.html
In the second page written that anyway hibernate should manage collection so it can do it only having it's own implementation of List interface.
Renat

[Ken Robinson]

Well it looks like Hibernate can only be used locally and not in a distributed environment unless Transfer Object are heavily used. Not that that's a complaint as I don't think Hibernate was intended for that, but that would have made things easier.
Again, since about 20% of my current project is required to be distributable and it's always desirable to use the same strategy for persistence, Hibernate is only a partial solution. We may just scrap the idea of serving distributed java objects and only serve XML in the distributed environment. This will probably allow us to use Hibernate all over and only convert the Hibernate generated beans to XML on the way out.