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 <[email protected]> To: ""[email protected]"" <[email protected]> Cc: Sent: Monday, May 7, 2012 3:03 PM Subject: BTreeManager - opt in or automatic? Hi, 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. Thanks, Dave
