With all due respect it very much sounds like you are doing this hard way,
if not the impossible way. Here's an example of some of my search code:
can see i'm using ISDESCENDANTNODE so limit search to only certain areas of
It sounds like you may be worried about queriying at every level of the
tree when you shouldn't. Can you just say what you are doing like: "I'm
trying to find all nodes that have a certain property value under a certain
portion of the tree". or smoething like that just to put it in plain
english. Or even sent an example of the kinds of queries you are trying to
run. I still think it's likely you don't need a custom indexer. It sounds
like you just need to find an approach that keeps your query from being
"order of N" number of parameters just because the tree depth is "N"
parameters. Normally the tree depth is never needed in a query. Also if you
DO need to run specific queries at each level then run MULTIPLE queries.
Don't try to create one massive query that runs all levels of the tree at
the same time. ISDESCENDANT node may be able to help.
On Thu, Oct 13, 2016 at 11:02 AM, rachna <rachana.me...@telegraph.co.uk>
> Hi Clay & Thomas,
> Thanks for your replies.
> We have previously developed a feature that uses the tag management system
> inside of AEM. The current business logic performs a search against the
> repository using the tags associated with the content page. As part of this
> business logic, the decendants of the tags (and decendants of these tags
> until the bottom of the tree is reached) are also added to the query. This
> creates a large query that isn't very efficient. We've hit the 1024 limit
> parameters for the query api.
> Our custom indexer analyses the decendants of the tags when the reindex
> operation is triggered so we can precompute this and store it efficently in
> the index.
> (We store the page path against the decendant tags in the index)
> Ideally we would want to query our index directly (e.g. native query) to
> return the results. From looking at the documentation for the lucene index,
> I can see this is possible.
> The documentation for the property index does not have the same query
> Is it possible to run a native query against a custom indexer?
> Otherwise, can we programmtically access a new NodeState?
> We've hit the 1024 limit on parameters for the query api. Also we've hit
> the 1024 limit on parameters for the query api.
> View this message in context: http://jackrabbit.510166.n4.
> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.