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.
Solved! Go to Solution.
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.
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.
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.