jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Reutegger <marcel.reuteg...@gmx.net>
Subject Re: Query Performance and Optimization
Date Fri, 09 Mar 2007 15:39:04 GMT
Jukka Zitting wrote:
> Note that the hierarchical content model of JCR is fundamentally
> different from the relational model. There is no way you could achieve
> such a mapping without major compromizes especially with residual item
> definitions but also with things like type inheritance and even
> handling of the tree structure.

there is a third way: use the database but do not expose/store nodes of 
different types in separate tables. it would be similar to what the current DB 
PMs do, but in addition make the following information available to queries:
- hierarchy information
- property values and types
- node name
currently this information is buried in the serialized item state.

the lucene query handler already does this because that's what is required to 
execute a query: the node name, the hierarchy information and values of properties.

yes, that's all you need. the type information is already present in the 
jcr:primaryType property value and the type hierarchy is given by the node type 
registry. IMO the node types do not have to be represented as separate tables.

> In fact I think the use of relational databases in the current
> database persistence managers and the incoming bundle persistence
> managers is a necessary evil until we come up with a "native"
> persistence model that achieves the required ACID features without the
> need for an external component to "do its thing". :-)

but will this native persistence model also have query support? the current 
jackrabbit design offers separation between data storage and indexing, but wrt 
data integrity and performance it is maybe beneficial to have both in one pot 
(at least in some cases).


View raw message