Hi David, andy,
David Nuescheler wrote:
to me it seems like we have a number of people on this list
asking for a jdbc persistence manager, but the one that we
have (the "orm pm") does not receive enough development
support by all those people that are interested in it?
if that really is the case then i would suggest that some
of the people that are using the orm pm are pitching in to
catch up with the rest of jackrabbit and make it
"production ready" ( whatever that means for an
unreleased project ;) )
Thanks David, I'm glad somebody else than me is saying that :) (for
those not in-the-know, I've been working on the initial implementation
of the ORM-PM.
i think that having another jdbc approach without scraping
the orm pm will only spread the seemingly small *developer*
base interested in supporting rdbms backed repositories even
thinner.
I wonder btw whatever happened to the iBatis implementation that was
done a while ago ? Any news ?
Anyway, my take on DB-based persistence managers is that they need :
- a caching system for performance
- to be able to handle transactions
- to be able to handle commit/rollback
- use mapping files to be able to change the table and column names as
they might conflict
- be as high-performance as possible (although we will always have the
performance cost of network traffic)
- allow for clustering
In those criteria, an ORM-based implementation seams reasonable,
especially the Hibernate one. It is perfectly possible to do all this
without an ORM, but it would mean re-developping part of an ORM anyway.
And as always, in terms of speed : memory > filesystem > db :)
Regards,
Serge Huber.
