wood burning stoves 2.0*
The moose likes Object Relational Mapping and the fly likes Somewhat frustrated Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Databases » Object Relational Mapping
Bookmark "Somewhat frustrated" Watch "Somewhat frustrated" New topic
Author

Somewhat frustrated

Mr. C Lamont Gilbert
Ranch Hand

Joined: Oct 05, 2001
Posts: 1170

I have a database program. First I created a plugin to do the persistence with straight SQL. It works pretty nicely. Then I thought why not try with JDO? This would give me a good opportunity to learn a new technology.

Well this has been frustrating. It just seems that I have done so much work that I can't really see how I have saved anything. This stuff is supposed to be 'transparent'. I think the charade should be dropped.

Sure it will eventually work. And it feels nifty. But I can't see any reduction in work, but do see large increase in learning curve as well as internal complexity. Considering I don't write nor understand the innards of a particular JDO implementation that my applicaiton will be based on.

Its not that Im down on JDO. I feel down on ORM in general. How am I saving over SQL?


When I was learning j2ee I could see that it was more complicated that I required, but there was always the idea that with J2EE you got free clustering of the application server. Something I wouldnt have to code directly to support. What am I getting with ORM by not writing my SQL directly?
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17250
    
    6

Well savings over SQL is subjective. For simple application, no you won't save time coding with an ORM tool. But the key here is that you will not have SQL directly in your code and tightly coupling JDBC, SQL, Database into your code. You need too have a seperation of concerns, so that you can reuse as much as possible. That is the key that an ORM tool provides. It makes maintenance much much easier, which is a huge cost savings. More so than saving an hour of two coding.

Mark


Perfect World Programming, LLC - Two Laptop Bag - Tube Organizer
How to Ask Questions the Smart Way FAQ
Mr. C Lamont Gilbert
Ranch Hand

Joined: Oct 05, 2001
Posts: 1170

I feel like instead of tightly coupling to JDBC I am tightly coupling to JDO or whatever. its different, but its still as pervasive. I do have more ability to tinker with the database format more easily, but i dont have control over the sql as much.

After doing it both ways I am left feeling no advantage. When I used an ORM I feel like I am leveraging someone else's work. So this should add value. It has not worked this way though as the amount of input from me did not decrease.

Perhaps ORM works best for folks that dont know SQL or anything about a database. Then they dont have to learn the stuff I did?
Vinnie Jenks
Ranch Hand

Joined: Apr 26, 2004
Posts: 207
I've spent the last couple of weeks learning Hibernate and building a couple of small apps w/ it...I'd have to say that I agree w/ you *mostly* and somewhat disagree.

I do agree that ORM technologies aren't some silver bullet that magically reduce the amount of code you write by half...in fact...it's harder if you're familiar w/ relational databases, sql, stored procedures, etc...as I have been for years...simply because you have an entirely new "simple" technology to learn - one that requires you to entirely re-think your database knowledge to conform to.

I do believe that Hibernate, for example, does in fact reduce the amount of Java code I'm writing but has increased the amount of XML I have to tend to. The reason I haven't lost hope is Hibernate's ability to allow SQL programmers to do their thing, if they must. It isn't so rigid that I can't go right down to the database if I don't want to.

Productivity gains can't be declared for *all* projects and *all* requirements...obviously...I can see where ORM would be overkill, overly complicated, and just a waste of time. It's a tool that is useful for a number of jobs...period.

On the other hand...the entirely new lexicon and myriad of techniques I'm required to learn in order to build something non-trivial is a bit overwhelming...to say the least.

I see it this way - eventually, if we're still writing object-oriented code in 10 years, ORM technologies will be a good springboard toward using either pure or hybrid object databases like db4o, etc. It will allow us to abstract our data as objects until eventually our data *is* objects...but that's just me hoping that OODB technology gains some serious traction in the marketplace.

That's my story and I'm stickin' to it.
Paul Sturrock
Bartender

Joined: Apr 14, 2004
Posts: 10336

We use Hibernate, not JDO - so I'm speaking about ORM in general not one particular implementation. Officially we support 5 database types, and multiple versions thereof. Before we used Hibernate we needed 1000s of lines of code to handle the differences between the platforms which gave us a huge maintenance headache. Now when a new database is added to our list of those we support we change a three things (a line in a properties file, hibernate.cfg.xml and add a dialect) and it just works. Far, far better than using SQL directly. We save months of coding effort, not hours, by doing this. We also push some of the support requirement on to Hibernate's official support staff, rather than having to fix issues with the "nuts and bolts" directly.


JavaRanch FAQ HowToAskQuestionsOnJavaRanch
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 41621
    
  55
I'd like to second Pauls opinion on Hibernate (haven't used JDO or other ORM tools). We use it in conjunction with the XDoclet Hibernate Ant task, which maintains the XML configuration files automatically. All the necessary information is kept in javadoc comments in the classes that are hibernated, so they are close to where the relevant information is kept in the source code.
Using Hibernate it's also quite easy to switch databases, which of course may not be any useful for you.
It's a definite time saver.
[ September 14, 2005: Message edited by: Ulf Dittmer ]

Ping & DNS - my free Android networking tools app
Mr. C Lamont Gilbert
Ranch Hand

Joined: Oct 05, 2001
Posts: 1170

When I first started into JDO I was excited for this very reason. I could create this bridge. And instead of me writing all the SQL I could let somebody else write it. That somebody else may even be me on some open source implementation of the spec. This way the common ORM work that we all do can be shared. We all benefit.

The road has been difficult. I suppose I'm just whineing.
Edwin Keeton
Ranch Hand

Joined: Jul 10, 2002
Posts: 214

Possibly the greatest benefit of a well-implemented ORM tool (like Hibernate) is caching. You can write the SQL, use a JDBC framework to ease the use of straight JDBC, and be more or less with a good ORM, but you can't beat cached objects.

Database transparency is a big hit too, but most (?) projects don't need it or don't care about it.

A big disadvantage of "straight" JDBC is that you need to write about 25 lines of "plumbing code" (managing resources and catching exceptions and whatnot) for every simple database hit you make. Hibernate, as one example, mostly eliminates this.

Not having to write SQL is a "false advantage" of ORM, IMO. You still need to thoroughly understand the generated SQL, and as you seem to be experiencing, it's just as challenging to declare mappings in XML as it is to learn SQL. It's just as bad to litter your code with HQL, or OQL, or JSQL, or whatever query language, as littering it with SQL. The answer, for whatever your chosen query language, is separating database queries into a data access layer.

JDO is more than an ORM specification as it also intends to handle all data persistence mechanisms, not just relational tables. This makes it more complicated than necessary if you only use relational database persistence.

I've been happy with Hibernate so far, and although I'm still on the steep slope of the learning curve, I've been able to successfully leverage its advantages in production code.

There are no magic bullets. We can only ease one headache by gaining a different one.


SCJP, SCWCD
Mr. C Lamont Gilbert
Ranch Hand

Joined: Oct 05, 2001
Posts: 1170

Well I wrote my own cacheing layer even before I decided to give ORM a try. its not all that complicated or hard. But lazy loading is something significant. Also i am seeing that I get transaction management as well. So some things are nice.

I thought persistence was part of ORM. How does hibernate differ from JDO in this case? You seem to indicate that JDO does something hibernate does not?

Originally posted by Edwin Keeton:

JDO is more than an ORM specification as it also intends to handle all data persistence mechanisms, not just relational tables. This makes it more complicated than necessary if you only use relational database persistence...


What do you mean by this? does hibernate not handle persistence? Perhaps there are more differences between hibernate and JDO than just the point at which they modify the classes?

Originally posted by Edwin Keeton:

There are no magic bullets. We can only ease one headache by gaining a different one.


bah, I'm still looking for the greener grass
Edwin Keeton
Ranch Hand

Joined: Jul 10, 2002
Posts: 214

What I meant was that Hibernate is specifically and exclusively designed for object mapping to relational tables, while JDO includes and is strongly influenced by support for object-oriented databases as well. JDO abstracts "database" (or maybe "persistent store") while Hibernate abstracts "relational database". By concentration on a smaller abstraction I think Hibernate is a little more friendly, at least for now. I think that JDO, Hibernate, and EJB concepts are merging and will continue to merge into either a beautiful, clean persistence abstraction, or a big ball of mud. I'm optimistic about this, and I'm looking for that greener grass too.
Pj Murray
Ranch Hand

Joined: Sep 24, 2004
Posts: 194
In addition to considering the Java persistence technologies (EJB CMP versus JDO versus JDBC versus Hibernate versus whatever else), you should also focus on a sustainable architecture using Data Access Objects.

This means that you can shield your application from the underlying technology (important, for example, for technologies with lots of releases/upgrades like Hibernate or technologies with new specifications coming out like EJB).

Using a DAO architecture also means you can experiment and change the underlying technology as required.


You might find this comparison of the various Java persistence technologies useful:

http://www.codefutures.com/weblog/corporate/archives/2005/02/data_persistenc.html


PJ Murray -
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Somewhat frustrated