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).
regards
marcel
