AEM QueryBuilder 'type=cq:Page' condition is not working | Community
Skip to main content
Level 2
November 28, 2019
Solved

AEM QueryBuilder 'type=cq:Page' condition is not working

  • November 28, 2019
  • 8 replies
  • 8155 views

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

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by leoberliant

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

8 replies

Adobe Employee
November 28, 2019

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"

Adobe Employee
November 28, 2019

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.

arunpatidar
Community Advisor
Community Advisor
November 30, 2019

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

Arun Patidar
Level 2
December 3, 2019

It's still not working for me

BrijeshYadav
Level 5
December 3, 2019

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

Level 2
December 4, 2019

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.

leoberliantAdobe EmployeeAccepted solution
Adobe Employee
December 4, 2019

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

kpawan
Level 2
June 19, 2021

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!!!