The generated schema and classes
worked without modification. It also has a great query language which seems
to really work. It also has a nice hibernate HQl data brower/query tool
giving you the real OO view of your database.
There is a similar tool for OJB, the OjbConsole. We don't ship it as part of the core distribution, but it is available at:
http://ojbc.sourceforge.net/
ojbc is really a cool tool! There is a live demo at http://www.scrashmeow.org/ojb/main/index.do. Give it a try!
Yes - Objc is cool...but Hibern8IDE and ojbc is two very different apps. They solve two similar but yet different problems.
<personal commercial on> Hibern8IDE runs standalone - does not require any webserver etc. and can be runtime configured to explore the mapping data.
Go see an early Hibern8IDE demo at http://www.xam.dk/hibern8ide/hibern8ide.swf (the newest version have more cool features ;) </personal commercial off>
;)
Best regards, Max
cheers, thomas
It really seemed to be more
complete/polished than other open source OR mapping. OJB seems it will suit
a wider variety of applications though.
-Ken
-----Original Message----- From: Mahler Thomas [mailto:[EMAIL PROTECTED] Sent: Monday, November 17, 2003 4:53 AM To: 'OJB Users List' Subject: RE: Persistence frameworks
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.
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.
<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.).
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...
So IMO best thing to do is to design for ultimate flexibility
from scratch.
> 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.
On the other hand Hibernate provides two things that OJB
does not -- a
forthcoming book
There are already several books available that have a decent coverage of OJB. (e.g. http://www.amazon.com/exec/obidos/ASIN/0596003285/qid%3D1054656123
/sr%3D2-1/
ref%3Dsr%5F2%5F1/102-4902036-7120135 and
http://www.amazon.com/exec/obidos/tg/detail/-/1861007817/qid=1054655953/sr=8
-1/ref=sr_8_1/102-4902036-7120135?v=glance&s=books&n=507846).
A book exclusive covering OJB is also under discussion.
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 --
Of course OJB allows you to provide your own connection lookup mechanism. It would take about 5 Minutes to write a ConnectionManager implementation that can work with user connections. Until today nobody requested this feature...
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 ;-)
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]
--------------------------------------------------------------------- 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]
