Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
BedrockMission!

Learn more

View all

Sign in to view all badges

SOLVED

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

iabhisheksinha
Level 2
Level 2

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

1 Accepted Solution
berliant
Correct answer by
Employee
Employee

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

1860600_pastedImage_0.png

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

1860601_pastedImage_1.png

If it is not valid, re-index /oak:index/lucene

View solution in original post

8 Replies
berliant
Employee
Employee

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"

index.png

aemmarc
Employee
Employee

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.

Arun_Patidar
Community Advisor
Community Advisor

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

BrijeshYadav
Level 5
Level 5

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

1860981_pastedImage_1.png

Here is result from querybuilder

1860982_pastedImage_2.png

iabhisheksinha
Level 2
Level 2

Not Working: -

1861175_pastedImage_1.png

Working:-

1861176_pastedImage_4.png

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.

berliant
Correct answer by
Employee
Employee

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

1860600_pastedImage_0.png

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

1860601_pastedImage_1.png

If it is not valid, re-index /oak:index/lucene

View solution in original post

kpawan
Level 1
Level 1

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