aem 6.5 Customize the OOTB index

[nbg621]

Investigating query which traverses 600k, think about adding index on the following criteria

[nt:base] as [a] /* lucene:ntBaseLucene(/oak:index/ntBaseLucene) :ancestors:/content/dam/folder1/folder2 where ([a].[jcr:content/metadata/my_prop] in('value1, 'value2', 'value3')) and (isdescendantnode([a], [/content/dam/folder1/folder2])) */

How should my index definition look like, for index on  "my_prop" ?

Thank you

[SantoshSai · Accepted solution]

Hi @nbg621,

Here’s how your index definition should look:

{
  "jcr:primaryType": "oak:QueryIndexDefinition",
  "compatVersion": 2,
  "type": "lucene",
  "async": ["async"],
  "evaluatePathRestrictions": true,
  "includedPaths": ["/content/dam/folder1/folder2"],
  "indexRules": {
    "nt:base": {
      "jcr:primaryType": "nt:unstructured",
      "properties": {
        "myPropIndex": {
          "jcr:primaryType": "nt:unstructured",
          "name": "jcr:content/metadata/my_prop",
          "propertyIndex": true,
          "analyzed": false
        }
      }
    }
  }
}

• includedPaths: Restricts indexing to the folder subtree you're querying (/content/dam/folder1/folder2), improving performance.
• evaluatePathRestrictions: true: Supports isdescendantnode() and similar clauses.
• propertyIndex: true: Enables indexing for exact match (IN, =) queries.
• analyzed: false: Ensures it's not tokenized, which is ideal for exact values like value1

[nbg621]

Does it make sense to keep

"evaluatePathRestrictions": true

if I remove: "includedPaths": ["/content/dam/folder1/folder2"],  

[SantoshSai]

@nbg621 

Yes, it still makes sense.

• evaluatePathRestrictions: true tells the index to support filtering based on path, such as when your query includes ISDESCENDANTNODE() or ISCHILDNODE().

• If you remove includedPaths, it just means your index is now applicable across all content paths - not limited to /content/dam/folder1/folder2.