I need to create a search index to address the traversing errors in error.log. Specifically:
.../* xpath: /jcr:root/content/solutions//*[(jcr:content/@page-category = 'category:news')] */, path=/content/solutions//*, property=[jcr:content/page-category=[category:news]]); consider creating an index or changing the query
.../* xpath: /jcr:root/content/solutions/en/stories//*[(jcr:content/@author = '/content/solutions/en/author/dan')] */, path=/content/solutions/en/stories//*, property=[jcr:content/author=[/content/solutions/en/author/dan]]); consider creating an index or changing the query
.../* xpath: /jcr:root/content/solutions//*[(jcr:content/@series = 'Press Releases')] */, path=/content/solutions//*, property=[jcr:content/series=[Press Releases]]); consider creating an index or changing the query
So it appears I need a property index for page-category, author, and series.
Explain Query tells me the Lucene index is more performant than a standard property index. So if I used Lucene, should it be 1 index with all 3 properties or 3 separate indexes?
There are many out-of-the-box Lucene property indexes. But I'm not sure if they are created that way to logically separate the properties or if it serves a purpose to have them separated.
Solved! Go to Solution.
Views
Replies
Total Likes
Hi,
yes, you can create a custom index, which contains these 3 properties.If you just do equality matches (as shown above), you don't need more settings in the index.
if you want to do work more sophisticated (e.g. fulltext conditions) I recommend you to check the JCR Query Cheatsheet for AEM [1].
Hi,
yes, you can create a custom index, which contains these 3 properties.If you just do equality matches (as shown above), you don't need more settings in the index.
if you want to do work more sophisticated (e.g. fulltext conditions) I recommend you to check the JCR Query Cheatsheet for AEM [1].
So I had opened a support ticket prior to this post and didn't get a satisfactory answer, which is why I posted here. However, eventually I got this response:
"If you have one index for all properties it will index all nodes that contain one of the properties, which can make the query less efficient. It is only recommended to use a single index when all of the properties being indexed are related to allow Lucene to evaluate as many property restrictions as possible natively."
What do you think?
Hi @Jörg_Hoh,
The linked cheat sheet is a great document -- very nicely organized, clear examples -- but it is no longer accessible. Do you mind to repost it somewhere so we can save it?
We updated the document into a version 1.1. Please bookmark this page where the latest version is always referenced:
https://www.adobe.com/go/aem_jcr_query_cheat_sheet
Thanks, and thanks for the quick response!
I have executed below three xpath queries using Oak Index definition generator to understand few things like type lucene, property index will be true or not as shown below -
From these structure I have understood we could create index with all 3 properties then it will help you -
@Jörg_Hoh , please correct me also.
Yes, you can merge all of these 3 indexes into a single index.
Understood. Something like -
yes
I know it's been a while, but I did want to close this out. Turns out all three properties were related to the same nodes/pages so a single index did indeed work, like you have @DEBAL_DAS. This is what mine looks like:
If you were deploying via package, this is the entry that would go in /jcr_root/_oak_index/.content.xml:
<myappLucenePropertyIndexArticleMultimediaPages jcr:primaryType="oak:QueryIndexDefinition" type="lucene" includePropertyNames="[author,page-category,series]" fulltextEnabled="{Boolean}false" async="async"/>
Views
Replies
Total Likes
Views
Likes
Replies