Hi, Could anybody describe the benefits of using Oracle Objects over JDBC (sqldata etc) vs Hibernate/Toplink? Oracle are singing about Objects/JDBC but all their examples seem to use Toplink! Many Thanks, K.
Oracle owns Toplink, so you shouldn't be suprised all their example are for it. The big advantage of Hibernate over thes two is it is genuinely platform independent. 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.
Let me give you some feedback from a project that used Toplink.
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.
We've done some projects using Toplink and also 9i databases. The support is quite okay... and all the features are in place. One of the main things i think you should ask yourself is what kind of application server is the application going to run on?
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.
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).
For a lightweight POJO persistence solution you're much better off with JDO than something like Toplink or Hibernate, simply because you have mutli-vendor support with JDO - i.e. no vendor lock-in via a proprietary API.
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...
Dave Clark<br />Senior WebSphere Architect<br /><a href="http://www.versant.com" target="_blank" rel="nofollow">Versant Open Access - JDO2 & EJB3</a>
Joined: Oct 24, 2004
Dave, it may sound strange, but my current client wants proprietary lock-in (although they wouldn't use that phrase, obviously).
They equate proprietary lock-in with proprietary support: which, according to them is a "good thing".
Regarding the original question there are some advantages to Oracle O/R views such as performance (Oracle uses parallel query and caching strategies for nested objects) and clarity, especially when using a good Oracle management tool like TOAD.
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.
I am quite agree with all of you. I am now in a process of evaluating Hibernate to work in conjuction with xml-db. Its the nature of my application to send and retrieve data from Oracle DB as a xml document. So When the size of my document is farele large let say 10mb then the whole network is on the knee. So surely I am in the opinion that flying by high speed train is better than a fighter jet because security is a more concerned. And of course there are other things to be concerned.