On 7/18/05, Serge Huber <[EMAIL PROTECTED]> wrote: > > 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
caching is taken care of in another layer. caching on the persistence layer is redundant and could aversely affect the overall performance by consuming to much memory which could be used more efficiently by jackrabbit. > - to be able to handle transactions > - to be able to handle commit/rollback agreed. you get that for free with jdbc. > - use mapping files to be able to change the table and column names as > they might conflict this depends on which approach you're taking. i favour the keep-it-simple approach (2 column tables as discussed in other threads, i.e. no mapping files required). > - be as high-performance as possible (although we will always have the > performance cost of network traffic) that's always a good idea :) cheers stefan > - 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. >
