Hi!

Just want to ask/clarify some stuff on this one - sorry for the late "answer" ;)

Happily:

OJB provides much more flexibility in caching; provides object-space transactions in a non-managed environment (if you are running in a J2EE container which provides JTA than this is probably a wash as you will probably want to use JTA for transactions and both OJB and Hibernate support using JTA);

May I ask what object-space transactions you mean OJB provides that Hibernate does not ? (Is it the ODMG stuff you are referring to, which requires extra tables in the db ?)

allows non JavaBean accessors (Hibernate uses getFoo()/setFoo(...) for all persistent field access, OJB can do that, or access fields directly, or access DynaBean properties, or figure out which one is being used for which field and choose the correct method, or you can implement a new field access strategy (it is pretty easy);

Correction ;)


Hibernate does support both property and field access now (since hibernate 2.1b4).
It also provides for custom field access strategy.

it can access non-relational data sources (pretty minor for most people, but it is a good example of the flexibility);

Same for Hibernate (but you cannot of course query this stuff with the same flexibility as you can with relational databases - I reckon OJB have the same "limitation")

, it supports more than one
API (the PB kernel (proprietary), ODMG 3.0 (published standard), OTM (proprietary), JDO 1.0 (published standard) compared to HQL (proprietary) and a promise to support JDO 2.0 whenever it is actually specified), and these can all politely interoperate;

Correct - but we do also support SQL (see createSQLQuery()). We also have an ODMG API - but noone seem to want to use it ;)

The biggest thing is a core design difference where OJB is designed to be very flexible and allow you to get exactly what you need whereas Hibernate is designed to do it one way and make that one way match what most people need.

Yes - that's probably the biggest difference between OJB and Hibernate. Hibernate want KISS, OJB want ultimate flexibility ;)

> Finally, the licensing issue is either a
huge difference or a doesn't-matter depending on your company's lawyers and/or how you intend to distribute the application -- OJB is ASL Hibernate is LGPL.

Just remember to read of license faq which states that Hibernate can be used in any project commercially or not - and without making your project opened source!

The only "limitations" is that you cannot fork Hibernate (write ya' own persistence 
engine)
and that if you make some improvements to hibernate you should submit them back
to the project.

On the other hand Hibernate provides two things that OJB does not -- a forthcoming book and the ability to easily hand it a JDBC Connection and have it use that Connection (this can be done via some voodoo-like runtime configuration of OJB, but isn't a good idea -- OJB pretty much needs to know the JNDI lookup for your DataSource in its configuration).

ok - did not knew that. I seem to remember using OJB before without requiring any kind of JNDI!?


Just my 2 cents ;)


/max


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to