Thanks Clay & Thomas.

Taking a step back from our problem has helped to look at it in a different

The tag property also stores the values in a specific format that show the
tree structure.

- location:europe
- type:waterfalls

Therefore instead of traversing the repository to identify the descendants
of these tags, we could use a LIKE query.

[/content/guides]) AND ([cq:tags] LIKE 'location:europe%' OR [cq:tags] LIKE
'type:waterfalls%') ORDER BY [cq:lastModified]

However, since our repository contains a large number of items that match
this criteria, we start to see warnings about traversing the index.
Traversed 210000 nodes (210164 index entries) using index jcr:primaryType
with filter Filter(query=SELECT * FROM [cq:PageContent] AS b WHERE
ISDESCENDANTNODE(b, [/content/guides]) AND ([cq:tags] LIKE
'location:europe%' OR [cq:tags] LIKE 'type:waterfalls%') ORDER BY
[cq:lastModified], path=/content/guides//*, property=[cq:tags=[is not

Instead, I created a lucene index that indexes the cq:tags (/w full text)
and cq:lastModified (/w ordered support) property.

e.g. SELECT [jcr:path] FROM [cq:PageContent] AS b WHERE ISDESCENDANTNODE(b,
[/content/guides]) AND (CONTAINS([cq:tags], 'location:europe') OR
CONTAINS([cq:tags], 'type:waterfalls')) ORDER BY [cq:lastModified]

That seems to be much faster than using a property index and should solve
most of the issues that we might have (hopefully avoiding creating a new

Is there any support with the lucene index to use something like STARTSWITH
rather CONTAINS?

The maxClauseCount configuration parameter introduced the soft limit of 1024
which is part of Jackrabbit 2.
We have been attempting to move to oak however our progress has been slow
due to repository inconsistencies.
I realise this value is configurable however constantly increasing it
doesn't sound the right thing to do.


View this message in context:
Sent from the Jackrabbit - Users mailing list archive at

Reply via email to