Aaron Longwell wrote:
I have only recently realized the awesome benefits of an O/R mapping tool. And I absolutely love OJB!
But I've been wondering if OJB is really the best solution for my projects. I typically have 100% control over the environment (small-medium sized projects with no legacy data and no RDBMS requirement).
If you are not required to use an RDBMS *and* you are familiar to object persistence APIs like ODMG and JDO, you are typically much better of with an OODBMS!
I once was architecting a solution for our company and did the prototyping with a an ODMG compliant ODBMS (Objectivity). I finished a persistent DOM implementation for parsed XML documents within 1 day!
Unfortunately the upper management refused to use an OODBMS instead of our existing RDBMS for production.
So I thought: "It would be great to code against the ODMG API and use the RDBMS as persistence backend. We urgently need an O/R mapping tool with an ODMG API."
The rest is history...
I'm wondering whether an actual object database might be better for these cases. Can those who have experience give some input on my questions?
1) What Open Source Object databases exist (for Java)?
A very cool solution is prevayler.sf.net. It's even cooler than an OODBMS (IMHO).
I'm thinking of providing a Prevayler based PersistenceBrokerImpl for some time now...
By doing this we could provide all the OJB APIs but without all the RDBMS related hassle.
There is also the classic OZONE (also provide an ODMG API)
You can search the sourceforge project list for dozens of other implementations
2) How does performance compare to OJB? (I utilize the object cache extensively)
prevayler is incredibly fast, as everything is kept in memory and there is no need to perform SQL queries. Everything can be reached by normal Java references.
3) How is development time affected? I'm guessing that systems designed around object databases take a little more front-end planning.
My experience with Objectivity and POET is that development time is drastically improved, as you have to think much less about data-management issues.
On the other hand you may have some more trouble in the long term because of "schema evolution", that is changes to your persistent classes. YOu have to make sure that instances stored before changing the class layout can still be used after applying the changes to the class!
This may be really tricky!
cheers, Thomas
Thanks for your input, Aaron
--------------------------------------------------------------------- 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]
