Proposed change:
- the pointer from child to parent should stay
- list of child nodes per node should be stored as a tree (b-tree or binary
tree)
- the list of references to a node should be stored as a tree as well
The actual b-tree implementation does not need to be in Jackrabbit. When
using databases as persistent manager, it is possible to use a regular
b-tree index for example. This feature may not supported by all persistent
managers.
this not only a problem of the storage in the persistence manager, but
rather how the items are layed out in memory. if every node state has
a list of child node entries, the update will always fail in case of
concurrent modifications. further, such updates MUST fail in the case
of ordered child nodes. otherwise the application can't rely on the
proper ordering of the nodes.
what is needed is a (b)tree representation in the memory which can be
dynamically loaded, if nodes are missing. and that support concurrent
hierarchy modifications, especially 'adding a childnode' (which should
be possible to propagate down to the pm).
how the items are stored in the persistence manager is secondary.
since at the time the data is stored, the 'consolidated' states are
already available in the shareditemstatemanager.
the references should probably be stored more finegrained. i.e. the
following operations should be supported by the 'referencemanager' and
the respective pms:
addReference(source, target)
modifyReference(source, target) // could be covered by addReference
removeReference(source, target)
getReferences(target)
getReference(source) // which is optional, since this is stored in
the property
regards, toby
--
-----------------------------------------< [EMAIL PROTECTED] >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---
