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
Solved! Go to Solution.
Views
Replies
Total Likes
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
Views
Replies
Total Likes
This all depends how you configure your Index. How are you implementing your Search. Are you using an AEM APIS - if so - which one?
Views
Replies
Total Likes
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
Views
Replies
Total Likes
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.
Views
Replies
Total Likes
If you override this and take out order by score - are you still seeing this?
Views
Replies
Total Likes
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
Views
Replies
Total Likes
Thanks, that is very helpful.
Views
Replies
Total Likes
Views
Likes
Replies
Views
Likes
Replies