hi serge, thanks for the comments.
> >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 :) no problem ;) > Anyway, my take on DB-based persistence managers is that they need : > - a caching system for performance i would largely disagree with that. since there is caching on the layer above the pm, i think that a pm-level cache does not really add much other than memory consumption. > - to be able to handle transactions > - to be able to handle commit/rollback true... what is the difference between the two points? > - use mapping files to be able to change the table and column names as > they might conflict not sure. of course there are a number of different ways on how someone could map a content repository to a relational database. however, i think there are a couple of very simple "hard coded" implementations that completely avoid conflicts without any configuration beyond standard jdbc. > - be as high-performance as possible (although we will always have the > performance cost of network traffic) well, i would assume that "to be as fast as possible" really is a non-functional requirement of any piece of software, especially of software that tends to be a bottle neck. so to me this is somewhat implicit. > - allow for clustering that is unfortunately not something that the pm can take care of see the jira bug and all the discussions around that. > 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. see above. i think the differentiators that orm brings to the table are not that significant to a persistence manager, while i think that the additional complexity is substantial. > And as always, in terms of speed : memory > filesystem > db :) well, not in general ;) regards, david
