jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Hausladen <david_hausla...@yahoo.com>
Subject Re: BTreeManager - opt in or automatic?
Date Tue, 08 May 2012 01:51:07 GMT
Under the assumption that it's opt in, I started an implementation of the Node interface that
adapts to the ItemSequence's NodeSequence (to minimize visibility of the org.apache.jackrabbit.commons.flat
classes).  The fact that NodeSequence returns Iterator<javax.jcr.Node> instead of javax.jcr.NodeIterator
makes it impossible.

----- Forwarded Message -----
From: David Hausladen <david_hausladen@yahoo.com>
To: ""dev@jackrabbit.apache.org"" <dev@jackrabbit.apache.org>
Sent: Monday, May 7, 2012 3:03 PM
Subject: BTreeManager - opt in or automatic?


I have some questions about BTreeManager and how it is used to solve the problem of large
sets of child nodes. We're converting a legacy document store into Jackrabbit, preserving
file paths. Unfortunately, we found that this legacy store was very flat in some cases and
when that is the case, performance suffers, in some cases dramatically. A few searches turned
up BTreeManager. But there's very little documentation of how to use it.

1.) First of all, is it automatically used by Jackrabbit to manage the children of all nodes,
or is it an opt-in feature?
2.) If it is an opt-in feature, does one need to always use ItemSequence to access the children
of a node?  Based on what I see of the code, it seems necessary since without the mapping
performed by ItemSequence, the backing nodes' getNodes methods would return the internal (hierarchical)
rather than the flat structure.  


View raw message