when you look at the code of createVersionHistory() in AbstractVersionManager:
[...]
// create deep path
String uuid = node.getNodeId().getUUID().toString();
NodeStateEx root = historyRoot;
for (int i = 0; i < 3; i++) {
QName name = new QName(QName.NS_DEFAULT_URI,
uuid.substring(i * 2, i * 2 + 2));
if (!root.hasNode(name)) {
root.addNode(name, QName.REP_VERSIONSTORAGE, null, false);
root.store();
}
root = root.getNode(name, 1);
}
QName historyNodeName = new QName(QName.NS_DEFAULT_URI, uuid);
[...]
you see that the path to the version history is built using the uuid
of the version history node. the idea is to create a good distribution
of the histories in the version storage. this is mainly because
jackrabbit can't handle large number of childnodes very well.
regards, toby
On 6/28/06, Giota Karadimitriou <[EMAIL PROTECTED]> wrote:
I would like to ask a general question regarding how version storage is
organized in jackrabbit.
From what I see for each version node in jackrabbit moving up from
parent to parent there is:
a) A parent version history node
b) parent of a is a version storage node
c) parent of b is another version storage node
d) parent of c is another version storage node
e) parent of d is root
so it's like:
root-->d(version storage)-->c(version storage)-->b(version
storage)-->a(version history)-->version_node
why are there 3 version storages?
'b' has 'a' as its only child but c does not have b as its only
child.what are these other children?
In general what do the second and third version storage nodes (c and d
in my example) contain?
Regards
giota
--
-----------------------------------------< [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 >---
