Hi Max,
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 ?)
The three high-level APIs (ODMG, JDO and OTM) provide full object level transaction management. They provide a full instance life-cycle model as specified by the JDO spec. By using JTA these tx managers can be integrated into J2EE containers or other JTA compliant tx managers.
Ok - this sounds VERY much similar to what Hibernate provides in the core.
The ODMG implementation *does not* require any additional tables in general!
- If you want to use special persistent collections (DList, DMap, etc) you
must provide additional tables to hold these entities. (AFAIK Hibernate does currently not provide support for the ODMG persistent
collections. I'm pretty sure that once you start to implement them you will
end up in providing some tables to hold their data...)
- If you want to run OJB/ODMG on a cluster you need an additional lock table
in the DB which is used to synchronize transactions across the cluster.
We do support ODMG persistent collections - but not collections of "everything". So, I'm not exactly sure why you need those extra tables for synchronizing information that the database already has elsewhere (at least that is how I see that information). (but again that depends on what you mean exactly by synchronized transactions across a cluster)
<snip>
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 ;)
My impression is that this was true some time ago, but you are adding a lot of pluggable features into Hibernate these days (Field access strategies, Cache implementations, etc.).
It's true that we are adding more and more plugs to the core - but that is just a natural evolution for the core.
I don't believe that a KISS approach works for a heavy duty O/R tool. Users
work in so many different environments with so many different
requirements...
We will never claim that Hibernate is the solution for any kind of system...we don't even think a persistence layer/ORM is the solution for many systems....but we do think that Hibernate provides the best ORM solution for applications that use a domain model.
So IMO best thing to do is to design for ultimate flexibility from scratch.
Well - that's the difference between the Hibernate mindset and OJB IMHO. And thus I think we will agree to disagree on this point ;)
> 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.
IMO this *is* a limitation! OJB was build to allow users to write their own persistence engines by reusing our code-base. Apart from providing object orient persistence API's it's also meant as a construction kit for persistence layers.
Yes - again a difference in views that will exist forever ;) We love our work, and want to see it used whereever possible - but we would like to harvest the fruits of extensions/enhancements of Hibernate, so the Hibernate gets better and better....
A book exclusive covering OJB is also under discussion.
Look forward to that.
According to Clark's law "sufficiently advanced technology is
indistinguishable from magic" (http://c2.com/cgi/wiki?ClarkesLaw). But the
OJB metadata and configurtaion framework applies patterns that are known for
ages and covered by tons of textbooks
(http://c2.com/cgi/wiki?MetaObjectProtocol,http://c2.com/cgi/wiki?TheArtOfTh
eMetaObjectProtocol). So calling it voodoo is really giving to much credit
to OJB ;-)
;)
/max
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!?
Correct, JNDI is not mandatory, it's an option.
cheers, Thomas
Just my 2 cents ;)
/max
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
