Your favorite ORM Tool and Why?

[Gregg Bolinger]

I am curious to know what everyone's favorite ORM tool is and why you like it over the other ones?
I have used Hibernate a little and it is pretty good. I have glanced at Castor.
What's the deal with JDO? Is the spec finished yet? Does anyone have any information beyond Sun's web page regarding JDO? When looking at some of the Open Source JDO implementations, it looks more complicated than the proprietary ones like Castor and Hibernate.

[Lasse Koskela]

I am curious to know what everyone's favorite ORM tool is and why you like it over the other ones?

I really don't have a favorite, yet, because I haven't used an ORM in a client project. I have played around with the upcoming Hibernate and it sure looks great.

What's the deal with JDO?

The 1.0.1 spec is finished. I'd suggest browsing JDOCentral.com for further info (the site was down as of this writing).

[Frank Carver]

It's not very well known, but I have played with SimpleORM a bit, and it is indeed quite simple.

[Lasse Koskela]

Hmm. The example implies that SimpleORM relies on static constructs -- have you had problems with threading?

[David O'Meara]

I've played with Castor, TopLink and Jaxor, and I still prefer Castor. It worked very well for everything we did with it. It was not seamless, that is it didn't do everything we wanted exactly as we wanted, but we managed to muddle through with the complicated bits.
I haven't used TopLink or Jaxor as much, but TopLink is OK and Jaxor I didn't like at all.
I found that in Jaxor you still coupled your Java code with the database - code still contains tanle names. Its Unit of Work implementation caused us some hiccups since you can't view an object created in the unit of work until it commits, so if anything else needs it, the object doesn't appear to exist. I'm also not a fan of code generation since we normally rely on our own frameworks with our own base classes.
TopLink maps SQL code to Java code, which is a bit wierd and not something I'm sure I approve of. It's also one of the most bloated APIs I've ever seen - they have methods for everything. I haven't managed to get anything running using TopLink, but I should only be days away
Just some random thoughs.
Dave.

[Rick Hightower]

I've used a few ORMs....
I have used Hibernate on a project or two. It is cool. I don't think I would use anything else.
A big thumbs up for hibernate.
Gavin King rules!

[Gregg Bolinger]

Originally posted by Rick Hightower:
I've used a few ORMs....
I have used Hibernate on a project or two. It is cool. I don't think I would use anything else.
A big thumbs up for hibernate.
Gavin King rules!

You like it that much huh? What are your opinions on the fact that JDO is supposed to be the big thing, and Hibernate is proprietary?

[Renat Zubairov]

Originally posted by Gregg Bolinger:

You like it that much huh? What are your opinions on the fact that JDO is supposed to be the big thing, and Hibernate is proprietary?

Yes, but the biggest problem with JDO - IT'S NOT ORM it's mapping between text files and objects, nothing more, nothing less.
And if you will have a look in JDO 2.0 - proposal draft (I believe it takes another year to make it final) you will see exactly that Hibernate is now .
Hibernate now have more features then JDO 2.0 (like search by example, for example)
Br.
Renat

[Ernest Friedman-Hill]

Yes, but the biggest problem with JDO - IT'S NOT ORM it's mapping between text files and objects, nothing more, nothing less.

This is a rather tremendous misstatement. JDO is a specification for an abstraction of a queryable data persistence layer. Sun's reference implementation uses flat files just so that it can be a standalone package that doesn't depend on your installing a database. But JDO is not the reference implementation -- it's a standard that could be implemented in more than one way. Most other implementations -- and there are quite a few now -- are backed by an RDBMS, not by flat files; for instance the active open-source TJDO project which supports JDO 1.0.1 .

[Renat Zubairov]

Originally posted by Ernest Friedman-Hill:

This is a rather tremendous misstatement. JDO is a specification for an abstraction of a queryable data persistence layer. Sun's reference implementation uses flat files just so that it can be a standalone package that doesn't depend on your installing a database...

That's true that most of JDO implementation (I guess 99%) is used not for text files, and not for OODB for example. BUT! Have you ever run into word "Relational" in JDO spec?
That's why I said that JDO isn't really Object-Relational mapping tool because its very general.
I suppose it's the same story as was earlier. Remember - "we will make all comptonent's distributed!!! And that's will be nirvana!" (EJB 1.0) and then "oops... it's damn slow and stupid, not all components should be remote" (EJB 2.0). The same picture - "we will work with everything, text files, OODBMS, RDMBS" - as a result JDO doesn't care about object-relational impedance and that's the biggest mistake.
Offcource one can get all relational optimizations in commertional product's but then - vendor lock in.
Br
Renat

[Ernest Friedman-Hill]

Offcource one can get all relational optimizations in commertional product's but then - vendor lock in.

This makes no sense. The whole point of JDO is that you write your Java code to the spec. Different JDO implementations will have different properties, and you can shop around for the best implementation. You can move from one implementation to another simply by dropping in new JAR files.
If some of those implementations use vendor extensions to boost performance, JDO has a standard mechanism for vendors to introduce them in metadata. The Java code won't change, just the XML metadata. Furthermore, by definition, vendor extensions in JDO metadata are ignored by other implementations. Therefore, you can take a vendor-customized JDO application and, at a moment's notice, drop in a different implementation without changing a thing. The performance might drop, or improve, but the code won't change.
Note that even the "class enhancement" used by JDO is standardized -- i.e., classes are instrumented to support persistence but the instrumentation is standard, and you don't need to re-instrument to move from one vendor's implementation to another.
So all in all, I respectfully submit that you may need to study the matter a bit more closely.

[Renat Zubairov]

Originally posted by Ernest Friedman-Hill:

This makes no sense. The whole point of JDO is that you write your Java code to the spec. ...
...
So all in all, I respectfully submit that you may need to study the matter a bit more closely.

Sorry Ernest, you didn't understood my post, I didn't mean bytecode portability issues under vendor lock in, I meant features like Query extension (obviously JDOQL need some enchanments) - how standatization in class enhancement or vendor specific metadata will help me if I'll use some vendor specific query extension? Another example - migrating, the JDO approach is quite fine for drop everything and generate schema again, but if the people in my company still whant to use SQL qiries (highly optimized quries) again I need to cast interface to implementation specific class.
Or another example - if I whant to detach object from transaction - quite often wish in user interaction, I can do it in Solarmetric, or in Hibernate .
I propose to create topic Hibernate vs JDO (or may be start again this on TSS
http://www.theserverside.com/home/thread.jsp?thread_id=20875#92479

I've seen alot of fairy tales about standarts and it's implementations (It remaind me good article "Standartization vs innovations"). But I'm talking about the way objects are composed. And my point is:
Strateforward approach in hight perfomance ORM is utopic - if you whant to get applications that works, and woks fine, fast, scalable and you not going to use text files (OODBMS, LDAP etc) as storage you should use Object-Relation mapping tools (I'm emphasis on world Relational).
Why? Because:
1. There are some special features that in Hibernate, epecially concerning relational structure of data storage. Those features directly affects object model we are going to store (for fast mapping). Examples are parrent-child relationship (another way in relational model), collections (again in relational model order is not stored)
2. Features in Hibernate is specially designed for RELATIONAL database. As far as I know Hibernate is differ from another tools ONLY BECAUSE it has strong emphasis on SQL queries optimizations. The main word here is SQL.
3. And finally I say it again. Hibernate has more features as JDO 2.0 will have in year or two (I don't count vendor specific features, they are really impressive sometimes).
So, for me choice is clear:
If you whant speed, reliability, only for RDBMS - Hibernate,
If you whant portability even for OODBMS - JDO.
Sorry for offtopic.
Br.
Renat
[ January 03, 2004: Message edited by: Renat Zubairov ]

[Ernest Friedman-Hill]

obviously JDOQL need some enchanments

This may be obvious to you, but it starts from the flawed premise that everything does and should look like an RDBMS. If you start designing an application by laying out tables, and the objects are just an afterthought, well, then I can't really argue with you. That's certainly one way to develop software. Not the way I choose to, but it's a way.
If you're using JDO as a transparent persistence mechanism as it's meant to be used, JDOQL shouldn't need to be used much at all; you can write major applications without touching it or any other query language.
A discussion like this one often comes up in the OODBMS vs. RDBMS debates. Do you query for objects, or do you just iterate containers? If you design applications in an RDBMS-oriented way, then an object might contain a flat (indexed) list of a million other objects. In that case, you may indeed need lots of JDOQL, perhaps with enhancements, or SQL, in which case JDO isn't for you.
But if you design object-oriented applications (and indeed, if you are used to designing data structures, rather than just letting an RDBMS hold your data) then you wouldn't design such a thing in the first place. You only need to "find" objects if you "lose" them in the database. If you never lose them in the first place, searching isn't an issue.

[Artti Jaakkola]

Currently I try to use Hibernate where it's possible. In my opinion Hibernate is one of the best things that has happened to Java so far (I have high hopes on upcoming EJB 3.0 spec also). Hopefully JDO 2.0 comes out quickly and standardizes functionality in Hibernate.
CMP and BMP implementations are forced to be slow by their specifications (mass updates, anyone?). I've also tried several other ORM technologies, but I really like Hibernate functionality, speed and it's brilliant API. I go along with Rick: Gavin and his team rocks!
[ January 03, 2004: Message edited by: Artti Jaakkola ]

[Renat Zubairov]

Originally posted by Ernest Friedman-Hill:

This may be obvious to you, but it starts from the flawed premise that everything does and should look like an RDBMS. If you start designing an application by laying out tables, and the objects are just an afterthought, well, then I can't really argue with you. That's certainly one way to develop software. Not the way I choose to, but it's a way.
If you're using JDO as a transparent persistence mechanism as it's meant to be used, JDOQL shouldn't need to be used much at all; you can write major applications without touching it or any other query language.
A discussion like this one often comes up in the OODBMS vs. RDBMS debates. Do you query for objects, or do you just iterate containers? If you design applications in an RDBMS-oriented way, then an object might contain a flat (indexed) list of a million other objects. In that case, you may indeed need lots of JDOQL, perhaps with enhancements, or SQL, in which case JDO isn't for you.
But if you design object-oriented applications (and indeed, if you are used to designing data structures, rather than just letting an RDBMS hold your data) then you wouldn't design such a thing in the first place. You only need to "find" objects if you "lose" them in the database. If you never lose them in the first place, searching isn't an issue.

That's true, Ernest, but anyway I think that programming especially for persistent is always tradeoff, and one should choose what is most appropriate. I think our conversation is becaming useless, however I'm happy that we had it, and may be it will be usefull for somebody.
As we are discussing "Your favorite ORM Tool and Why?" I'm still believe that for object-relational mapping one should use object-relational mapping tool.
Br.
Renat

[Gregg Bolinger]

As we are discussing "Your favorite ORM Tool and Why?"
That's what I would like to know.

[Erik Bengtson]

In the object-relational world what mostly impact on your application performance is how you navigate thought your objects, and it's not JDO or Hibernate specific. It's all about the mature (intelligent) enough implementation that will be capable to know the best path (the best SQL) to access the objects and provide the best performance.
To provide a hint to the implementation on how your application navigate through objects, JDO has the default fetch groups or the implementation specific, to be standarized in JDO 2.0, the user defined fetch groups.
On the other hand, Hibernate has a more powerful query language that enables you create a pseudo query, translated by Hibernate to SQL, specific for your needs.
Many JDO implementations also provides you direct access to SQL.

"Your favorite ORM Tool and Why? "
I'm too biased to say, but if you want try a JDO open source implementation
http://jpox.sourceforge.net

[Renat Zubairov]

>
>Originally posted by Erik Bengtson:
>
>In the object-relational world what mostly impact on your application
>performance is how you navigate thought your objects
That's true, Erik, completely agree with you, and also how parent-child relationships are created and where IDs are stored (here we can see "object-relational impedance" because in relational tables link to the parent entity made from child entity, but in OO is other way around) and also how is inheritance is represented in relational DB. On the Hibernate site exists special guide for creating collections (several different types of collections) and collections for performance guide and
>and it's not JDO or Hibernate specific. It's all about the mature
>(intelligent) enough implementation that will be capable to know the best
>path (the best SQL) to access the objects and provide the best performance.
But good object-relational tool can optimize some parts, like "ops-no" requests, batch SQL, etc.
>To provide a hint to the implementation on how your application navigate?
>through objects, JDO has the default fetch groups or the implementation
>specific, to be standardized in JDO 2.0, the user defined fetch groups.
In Hibernate it's already implemented.
>On the other hand, Hibernate has a more powerful query language that
>enables you create a pseudo query, translated by Hibernate to SQL,
>specific for your needs.
Completely agree. Also query by example - completely new feature. And we all know how perfomant SQL is, and there special flag will show you all SQL commands that is done by Hibernate in order to optimize perfomance.
>Many JDO implementations also provides you direct access to SQL.
Not in standard JDO, and it will never become part of the standart because SQL is used only for RDBMS.
In Hibernate one can get direct JDBC Connection within current transaction, execute query and then return query result back to Hibernate for parsing for example.
Or one can detach objects from the transaction and then attach them to another.
[ January 06, 2004: Message edited by: Renat Zubairov ]

[Gregg Bolinger]

Ok people. I've enjoyed all this JDO vs Hibernate for about as long as I can.
I started this out with a simple question.
"What is your favorite ORM tool and why?"
I understand that they "why" part of my question might entail some comparisons to other ORM Tools. But this post has strayed from the origianl topic.
Please stick to the subject of this post. If you want to have a battle between Hibernate and JDO, then start a Hibernate vs JDO thread.

[Lewin Chan]

Gregg,
The "My dad is better than your dad" kind of thing always crops up when you have a "Which is your favourite" thread.
I don't have a favourite, I just use the tool that's quickest for the job at hand. Familiarity with a tool doesn't necessarily mean that it's good.
Generally, I have a situation where I have an existing database, and an existing set of objects, and I need some way of persisting those objects into that database... It's not always possible to have a simple relationship between the two. In this kind of situation, I generally end up using Ibatis, I can do my fancy selects in the xml descriptor file. It's simple and easy to use.
In a sense, it's easier to maintain as pretty everyone understands SQL even if they don't know java, and the database man can tweak the SQL to his hearts content.
I know that Hibernate can do something pretty similar, I've played with it, even managed simple relationships. You know the rest though, time pressures generally mean that I can't justify going all out and trying to figure out all the idiosyncrasies of it.
L

[Joel McNary]

Just as a warning, I've not read all of this thread. (I got tired about halfway through and skipped the JDO vs. Hibernate bits...)
I've been using ORM tools for over five years now, in both Objective-C and Java. Two-an-a-half years ago when I first started in Java, I could not find any tools that compared to how we accessed data in our company's Objective-C toolkit, so I wrote my own. It's been indevelopment now for those years, and (not suprisingly) it looks a lot like what I know of JDO (I don't know Hibernate so I can't compare). In fact, with a little bit of tweaking, it could be a "vendor implementation" of JDO. (Well, OK, the XML metadata would require more than a bit of tweaking, but I already use XML metadata in my persistence engine, so it wouldn't be that much of a strech.)
As such, my favorite ORM tool is the one that I wrote. Since I wrote it, I have the code, and anytime it needs to do something, I can enhance it. I've written several applications in Java without writing one line of SQL -- my engine does it for me (if needed).
And yes, when I design a system, the first thing I design is the data structues. In my experience (and clientele), Business requirements drive data structures. If your data is structured correctly, the resulting application should meet your customer's needs almost by default.
Once I have the data structure, I can then build the code and the database/XML files/flat text files/whatever is appropriate. (In fact, my tool, called RACE, will generate DDLs for tables, Java code, and my required Metadata for me; and I'm working on it generating default JSPs). I deally, I would then be able to design my data structures and then RACE will essentially generate a fully-funtional application for me from that information.
In the future, I'll use whatever ORM the client wants to use. Left to my own devices, I'll use mine, simply because I know it best (and I've put too much effort into it to simply drop it...)
Just my experience and my $0.02

[Bear Bibeault]

Joel's post could have been written by me. (Perhaps with poorer grammar).
I started development on my own ORM tool back a few years ago, and as such, it suits me to a 'T'. (In the same manner I use my self-developed web app framework in favor of behemoths like Struts).
I use it in all my data-driven web apps.
This is not to advocate that everyone should write their own; I'm just answering your initial question.
bear

[Matthew Phillips]

I really like OJB. It is very simple to use, although the documentation could use a little work.

[Mike Rettig]

Originally posted by David O'Meara:

I found that in Jaxor you still coupled your Java code with the database - code still contains tanle names. Its Unit of Work implementation caused us some hiccups since you can't view an object created in the unit of work until it commits, so if anything else needs it, the object doesn't appear to exist. I'm also not a fan of code generation since we normally rely on our own frameworks with our own base classes.

With Jaxor, you can use the 'alias' attribute in the xml files to override the table name or column name defaults.
What do you mean by 'view' an object in the unit of work? In the present (3.4) release, all objects are cached by primary key in the unit of work. When you do a primary key query it will read it from the cache and not from the db. You can also use the flush() method on your JaxorContext to insert an object into the db, but not commit db transaction. This will make it appear in any sql query for your session so long as your DB supports this level of transaction isolation.
Regards,
Mike Rettig
Jaxor Developer
http://jaxor.sf.net

[HS Thomas]

Hibernate in Action: Practical Object/Relational Mapping
A Hibernate Query Language. Hibernate also makes it easy for you to fall back to native SQL, if required. I think it's good to have the two alternatives in one tool. Any opinions on this ?