Custom Index Migration from 5.6 to 6.2

[courtthreeGDC]

Hi guys,

We are in the process of migrating our site from 5.6 to 6.2 and have had great success in nearly every regard - except replicating the custom index. This, of course, is having a profound effect on the search results returned from the rep. Our 6.2 instance is a "clean skin". We elected to install a fresh 6.2 instance and migrate over only what we needed as a much overdue spring cleaning exercise.

As a result, the content of the site has NOT been through an in-place upgrade. It has been packaged and installed on the 6.2 instance like any other node.

I suppose my opening questions are:

"Can you use the OAK:Index node to create custom indexes for a content node that has not been through the in-place upgrade procedure? Will adding nodes to the OAK:Index as described by Adobe here https://docs.adobe.com/docs/en/aem/6-2/deploy/platform/queries-and-indexing.html have any effect on an 'un-upgraded' content node? Is this even the correct procedure full stop?".

Any advice would be very welcome indeed.

[MC_Stuff · Accepted solution]

Hi,

• You can create custom index.
• Content node and property matters for index. Weather upgrade or non upgraded index does not know. 
• Make use of http://oakutils.appspot.com/generate/index to know the index definition for your query.

Thanks,

[courtthreeGDC]

Hi MC Stuff,

Thanks so much for replying. I have done as you suggested and used the link above to generate the index for some XPath queries.

The kind of output I am getting is great. I am just not fully clear on how to copy it to the index because I'm not sure which node is should be a child of. Consider this output:

- evaluatePathRestrictions = true - compatVersion = 2 - type = "lucene" - async = "async" - jcr:primaryType = oak:QueryIndexDefinition + indexRules + cq:PageContent + properties + template - name = "cq:template" - propertyIndex = true + title - name = "jcr:title" - analyzed = true + hideInSearch - name = "hideInSearch" - propertyIndex = true - nullCheckEnabled = true

My instinct was to add the properties to PageLucene but Page Lucene has two child nodes, neither of which are cq:PageContent. Should I just add it as a new node. A steer would be very, very welcome.

[MC_Stuff]

Hi,

At the moment it is open debit to modify existing or new index definition. Both approach have pros & cons and can use either.   The fixes provided by adobe are without proper QA,  hence we are creating a separate index definitions for our custom quires.

Thanks,

[courtthreeGDC]

Thank you again. Yes, what the documentation doesn't make clear is that you can add a node and give it any name you like. Then you can add your custom nodes to it based on the output from http://oakutils.appspot.com/generate/index. Your assistance did indeed point me the right direction, thanks again.

I can confirm that the in-place upgrade was not necessary (contrary to Adobe's official advice) and that the custom index node will work on the existing content taken from our old 5.6 instance.