Expand my Community achievements bar.

SOLVED

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

Avatar

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

Avatar

Correct answer by
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

Avatar

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

Avatar

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.

Avatar

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



Arun Patidar

Avatar

Community Advisor

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

Avatar

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.

Avatar

Correct answer by
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

Avatar

Level 2

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