jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nuescheler <david.nuesche...@gmail.com>
Subject Re: Considering Jackrabbit
Date Mon, 18 Jul 2005 13:41:33 GMT
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 ;)


View raw message