I'm implementing fulltext search in AEM using Query builder. Below is the predicate map:
p.limit=-1
2_group.1_fulltext=*cost*
1_group.p.or=true
orderby.sort=asc
p.offset=0
orderby=@jcr:score
type=cq:Page
2_group.2_fulltext=*cost*
path=/content/<some-path>
2_group.p.or=true
2_group.2_fulltext.relPath=jcr:content/@jcr:description
2_group.1_fulltext.relPath=jcr:content/@jcr:title
This was working fine. But now it is returning zero results. I've to remove type=cq:Page
condition to get results. This has subsequently slowed down the query processing.
p.limit=-1
2_group.1_fulltext=*cost*
1_group.p.or=true
orderby.sort=asc
p.offset=0
orderby=@jcr:score
type=
2_group.2_fulltext=*cost*
path=/content/<some-path>
2_group.p.or=true
2_group.2_fulltext.relPath=jcr:content/@jcr:description
2_group.1_fulltext.relPath=jcr:content/@jcr:title
What might have caused this change and how to fix this?
Predicate map testing on - http://localhost:4502/libs/cq/search/content/querydebug.html
AEM version - 6.4
Service Pack - 6.4.6
Solved! Go to Solution.
Views
Replies
Total Likes
It has nothing to do with jcr:mixinType. As per a Query Explanation, your query should be served by oak:index/lucene:
/libs/granite/operations/content/diagnosistools/queryPerformance.html
Try to employ checkConsistency MBean to verify that /oak:index/lucene is valid
/system/console/jmx/org.apache.jackrabbit.oak%3Aname%3DLucene+Index+statistics%2Ctype%3DLuceneIndex
If it is not valid, re-index /oak:index/lucene
It looks like you are trying to make a join search for title "cost" OR description "cost" from a page under path=/content/some-path
i.e. the XPath query should be something like:
/jcr:root/content/some-path//element(*, cq:Page)
[
(jcr:contains(jcr:content/@jcr:title, '*cost*')
or jcr:contains(jcr:content/@jcr:description, '*cost*'))
]
order by @jcr:score
As such the query wil use OOTB /oak:index/cqPageLucene/indexRules/cq:Page. A correct syntax for a query builder predicate should be:
type=cq:Page
path=/content/some-path
group.p.or=true
group.1_fulltext.relPath=jcr:content/@jcr:title
group.1_fulltext=*cost*
group.2_fulltext.relPath=jcr:content/@jcr:description
group.2_fulltext=*cost*
p.limit=-1
p.offset=0
orderby.sort=asc
orderby=@jcr:score
Note, that OOTB cqPageLucene has only a title property:
/oak:index/cqPageLucene/indexRules/cq:Page/properties/jcrTitle
If you are querying for a description property you might want to edit the cqPageLucene by adding "description"
In addition to what berliant said.
If you are doing full text search you probably want cq:PageContent and not cq:Page itself.
When in doubt turn on debug logging for queries and you'll see the thing you type in QueryBuilder gets outputted as XPATH and JCR-SQL2. You can compare the resulting queries between your working and non-working to understand the true underlying query that is being run.
you can try with like operation as well.
Example -
type=cq:Page
path=/content/we-retail
property=jcr:content/jcr:title
property.value=%cost%
property.operation=like
It's still not working for me
Same query absolutely work fine and return results.
Did you tried querybuilder generated Xpath query in tools query console from crx/de to verify that result is same at both place?
/jcr:root/content/we-retail//element(*, cq:Page)
[
(jcr:contains(jcr:content/@jcr:title, '*cost*')
or jcr:contains(jcr:content/@jcr:description, '*cost*'))
]
order by @jcr:score
Here is result from querybuilder
Not Working: -
Working:-
I've an alternate theory. We have migrated page content programatically form non-editable templates to editable templates node structure. There are
jcr:mixinTypes | Name[] | mix:versionable |
and other relative properties.
Could these be the broken properties which are present on the "jcr:content" node which are present just as part of migrated properties and not valid features?
Could this be the reason of type:cqPage not be working? Or could it be due to service pack update?
Note:- This was working previously, but we lost the exact timeline of migration and this not working to co-relate and conclude this accurately.
It has nothing to do with jcr:mixinType. As per a Query Explanation, your query should be served by oak:index/lucene:
/libs/granite/operations/content/diagnosistools/queryPerformance.html
Try to employ checkConsistency MBean to verify that /oak:index/lucene is valid
/system/console/jmx/org.apache.jackrabbit.oak%3Aname%3DLucene+Index+statistics%2Ctype%3DLuceneIndex
If it is not valid, re-index /oak:index/lucene
I had the same problem and was trying to find out the root cause since this was working fine on higher environments and then when executed that query at http://localhost:4502/libs/granite/operations/content/diagnosistools/queryPerformance.html, i got the root cause which was following -
I had two custom indexes with cq:Page which was causing this problem and I deleted the one which I had created for some POC purpose and I am getting the result now -
/oak:index/<custom-index>/indexRules/cq:Page - 2 such indexes lead to this issue.
Hope this helps someone!!!
Views
Likes
Replies