Expand my Community achievements bar.

Don’t miss the AEM Skill Exchange in SF on Nov 14—hear from industry leaders, learn best practices, and enhance your AEM strategy with practical tips.
SOLVED

Simple OOB Search Index

Avatar

Level 2

We've implemented the simple OOB search on an AEM6.3 instance. The search returns the results as expected but I keep getting an Info message in the logs suggesting we create an index. That would be fine expect that query the log seems to be executing doesn't seem to reflect the search we've set up.

The search code looks something like this (simplified for the purpose of the example):

     Search mySearch = new Search(slingRequest);

     mySearch.setSearchIn("/content/wtrbop/home/");

The log entries look something like:

17.04.2018 17:15:02.981 *INFO* [0:0:0:0:0:0:0:1 [1523981697019] GET /content/wtrbop/home/search.html HTTP/1.1] org.apache.jackrabbit.oak.query.QueryImpl Traversal query (query without index): select [jcr:path], [jcr:score], * from [nt:base] as a where [queries] = 'findme' and [avgPosition] is not null and isdescendantnode(a, '/var/statistics/results')

1. Where is the /var/statistics/results coming from?

2. Do we need to create an index for /var/statistics/results and if so what should it look like?

I noticed a related query from last year but it never got an answer.

Re: AEM 6.3 upgrade issue in Search functionality

1 Accepted Solution

Avatar

Correct answer by
Employee

I assume you are using the SimpleSearch API and there has been an improvement done in the API to cater to the situation you are facing.

This has been taken care of in 6.4 so for 6.3, creating a dedicated index should work as a workaround. If you need to reach to support, you can mention #GRANITE-18313

View solution in original post

6 Replies

Avatar

Level 10

This all depends how you configure your Index. How are you implementing your Search. Are you using an AEM APIS - if so - which one?

Avatar

Employee Advisor

the reference to /var/statistics/results is indeed interesting, and you need to find the reasons for it. But if you don't know that you should not create an index for it.

Jörg

Avatar

Level 2

What we are using is based on the OOB jsp search component. Looking at the libs/granite/operations/content/diagnosis/tool.html/granite_queryperformance I can see the OOB query translates to this:

(/jcr:root/content/wtrbop/home/core//element(*, cq:Page)[(jcr:contains(., 'gas') or jcr:contains(@jcr:title, 'gas') or jcr:contains(@jcr:description, 'gas'))] | /jcr:root/content/wtrbop/home/core//element(*, dam:Asset)[(jcr:contains(., 'gas') or jcr:contains(@jcr:title, 'gas') or jcr:contains(@jcr:description, 'gas'))])/rep:excerpt(.) order by @jcr:score descending

It is not clear why this query for cq:Page elements is triggering a suggestion to index /var/statistics/results . I am guessing this may relate to the jcr:score. 

Avatar

Level 10

If you override this and take out order by score - are you still seeing this?

Avatar

Correct answer by
Employee

I assume you are using the SimpleSearch API and there has been an improvement done in the API to cater to the situation you are facing.

This has been taken care of in 6.4 so for 6.3, creating a dedicated index should work as a workaround. If you need to reach to support, you can mention #GRANITE-18313

Avatar

Level 2

Thanks, that is very helpful.