Oracle are singing about Objects/JDBC but all their examples seem to use Toplink!
Also, there has been an interesting development in JRS 175 with the early specs looking like Sun will be basically copying Hibernate's design for the next Entity bean implementation. Which of course makes Hibernate look like a more relevent technology (from a developer's point of view anyway) than others.
The DBAs are keen to use Oracle Objects, which to us j2ee folk, looks very unpleasant indeed. We're currently divided between hibernate and toplink/jdo.
Myself I'm leaning on the Hibernate solution, mainly for it's huge support and momentum. We're currently doing a POC which should weed out which is most appropriate.
Does anybody else have experience with any of the above and 9i?
Toplink was generally pretty good at doing O/R mapping in general and was easy to get started. We had some learning hurdles concerning the ExpressionBuilder syntax, but we got over that.
One issue that we did have was the Mapping Workbench. The mapping workbench is very fragile. If any of its generated project files get out of whack you can't rebuild the project - it probably won't even load. The MWB is so fragile that it won't even attmept to re-import a working project. It's a very dubious little tool. The only good thing is that the MWB project files are all plain text, so you can fix them up once they become hosed. There are also some settings in Toplink that cannot be set by the MWB. You will have to manually update the generated mapping file(XML or .java).
Right before our Toplink guy left, he, myself, and another developer had to spend about two days to get the MWB back together and checked into PVCS. BTW Toplink doesn't seem to like *any* version control.
I guess the upshot is that the technology is solid, but the MWB isn't.
Maybe a seemingly irrelevant question, but if you want to use TopLink you need an Oracle 9iAS license... Hibernate i thought was devoid of such licenses.
Until now we have been able to map everything we needed in Toplink. Although sometimes using a workaround...
We've used BLOB's succesfully using Toplink and the Oracle 9i database.
Also the mapping workbench of toplink is quite good... and i personally like the feature that you don't need an XML to configure your Toplink sessions/server/etc. You can just use classes and methods...
At the moment we are considering looking at Apache OJB and Hibernate, but that is more due to a customer wish to pay less license fees than that Toplink lacks features we need...
Esp if you need database mapping or integration with existing applications, you might be interested to check our product out.
PowerMap JDO is basically a heavy-weight data access & integration engine and configurability/ GUI tools, hooked up to the JDO mgmt api. This gives us some quite powerful and distinct capabilities, and puts within a nice standards-based framework.
If you've got budget for your project, or just to check the cool Eclipse integration, we'd definitely recommend you download a trial.
I thought I'd let you all know which way we went. We decided to use Hibernate in the end, this took some convincing of the rather large DB team (Now a lot smaller due to our choice...).
After 3 months of working with Hibernate, we are happy that it can do all we need. The on-paper features that Toplink boasts over Hibernate (eg. multi-table one file mapping) are promised for hibernate 3.
I am now of the opinion that Toplink will become yet another sales driven technology (like Oracle? ) as Hibernate really does seem to have the ORM problem all sewn up.
A couple of other tips: The hibernate PDF docs are worth printing out. We bought a few books and all except Hibernate in Action just repeated what was already contained in the docs.
Thanks to all!
I'm curious: how did you pitch the support issue for Hibernate to management? Ie: what is your plan of action when Hibernate breaks, or otherwise misbehaves in your production environment?
With TopLink, for example, you can create a TAR with Oracle and have them look at the problem.
You might find this blog entry useful "Choosing a Java Persistence Strategy"
I'm curious: how did you pitch the support issue for Hibernate to management? Ie: what is your plan of action when Hibernate breaks, or otherwise misbehaves in your production environment
Hibernate support is offered via JBoss support contracts, since Hibernate is part of JBoss Inc. now. Either on a pay per incident basis or with a longer term support agreement. JBoss staff offer consultancy in Hibernate too (the consultants include the core Hibernate developers).
Even though Hibernate is open-source, it's still proprietary, because it doesn't implement a standard API, and you can't just unplug it and plu-in a different vendor's implementation.
And there are around 25 different implementations of the JDO standard - both open source and commercial. A good open source implementation is JPOX. Good commerciial implementations are Versant's Open Access (for RDBMS's as well as ODBMS),, Solarmetric's Kodo, and others...
A major disadvantage is a lack of runtime flexibility in that you are locked into design-time View definitions and your ability to use different load strategies (lazy or greedy) is compromised.
We built a persistence layer around Oracle objects, and it was quite successful. However, for the reason cited above we will likely move on to a hybrid approach, perhaps with Hibernate. This will not be difficult for us b/c we maintain our logical model not in code, but in annotated .xsd files from which we generate all of our base ORM classes. This approach insulates us from any lock-in problems and makes model evolution completely painless.
Originally posted by Roy Mart�nez:
I would like to know your position. In the companny, we are using Oracle 9i, so I would like to use Top Link, do you agree?
[ May 07, 2005: Message edited by: Roy Mart�nez ]
I think you need to supply more information:
Which application server are you using?
Different ORM tools naturally have better support for certain application servers (Oracle AS for Toplink, JBoss for Hibernate)
Are you using Data Access Objects in your architecture?
Some tools have better support for DAOs than others. There's several advantages of using the DAO approach.
Is paying runtime/deployment fees an issue?
Would you prefer to have access to the source code?