Hi,
Marcel Reutegger wrote:
Florent Guillaume wrote:
I have a node that has lots of unordered children nodes. Some of these
nodes are "real children" in the document management sense, the others
(in small number) are just nodes that hold complex datatypes but are
really part of the main document.
I'd like to access both categories of nodes in an efficient manner:
- get only the nodes for my complex datatypes,
- get the list of "real children" nodes.
when you say 'get a list of child nodes' isn't it easier just using the
api instead of a query? Node.getNodes() and then have a custom
NodeIterator that filters out unnecessary nodes?
An iterator that filters while iterating would be ok when most of the nodes
match, but in the case where the nodes that I want are those in small
numbers (and which may be at the end of the iterator list), it's
inefficient. That's why I mentioned indexed queries.
I have flexibility in deciding how these node are typed. I can have
mixin types that are used as marker interface for these two
categories. Or (preferably) I can rely on the supertypes for my node
types to distinguish between the two.
What would you recommend so that my queries are processed efficiently,
using underlying indexes?
using different types for the child nodes is definitively a good idea,
as it helps narrowing down the set of nodes that may match.
If I have the (non-mixin) types:
[my:bar]
...
[my:foo] > my:bar
...
[my:gee] > my:bar
...
the spec (6.6.3.2) tells me that I can query
//element(*, my:bar)
and I'll get my:foo and my:gee nodes too. But is this implemented in
jackrabbit using efficient indexes, or is there an iteration and comparison
going on?
Thanks,
Florent
--
Florent Guillaume, Nuxeo (Paris, France) Director of R&D
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
