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.

Custom oak:index for content fragment causing issue on query result

Avatar

Community Advisor

We are using a lot of content fragment on our aem 6.5 project. On backend we do search for content fragment based on path and datetime combination. Recently we have added a custom property oak index only for our content fragments. From the query performance tool we checked that query is picking proper index.

But the problem arrises when there is any update on content fragment data the query result is still the same. If we manually reindex the custom oak:index that we created, then it works again.

Also sometime the result is not as expected. But got fix if we manually reindex the specific oak:index.

What could be the issue? Are we missing something? I am sharing a screenshot here.

Note: The querybuilder console result and code result is always same for the same query.

kaikubad_0-1724808003005.png

 

4 Replies

Avatar

Community Advisor

Both author and publish are behaving same or is there any difference ?
Are you updating the content fragment programmatically or when you update it manually then also you are facing the issue ? 

Avatar

Community Advisor

yes same for author and publisher.

and we don't change content fragments programmatically. Only the author changes the content fragments.

Avatar

Community Advisor

I have not worked on it directly, but I checked the documentation (https://adobe-consulting-services.github.io/acs-aem-commons/features/ensure-oak-index/index.html ) and there seems to be a property mismatch forceIndex vs forceReindex Not sure if that has anything to do with it though.
Also you probably don't need recreateOnUpdate. Check this https://github.com/Adobe-Consulting-Services/acs-aem-tools/issues/201 
Sorry, couldn't be of much help here. 

Avatar

Community Advisor

yes, those extra properties are there because we are using acs commons ensure oak index.