Question

I have a Sitecore content structure where any single item can have a number of child items that are used to store enumerable content for lists (obviously a fairly standard approach). I am hoping to index these items but store their index data against the parent doc in Lucene. This should hopefully speed up the search bit, by saving time sorting through multiple results which all effectively point to the same URL. Below is some basic code for the custom indexer I will implement.

Can anyone let me know if this is (a) possible and (b) a good idea? The main issues I see are that the Lucene doc already looks like it has been created – do I need to delete it? Also, if the Lucene doc for the parent item does not exist, do I need to create it? And will it be overwritten/lost when the parent item is indexed. Looks like a bit of room of conflict there.

Another option is that I don’t index child items, but get their values when I am indexing the parent. Now that I think about it, this seems like the better way to go.. opinions?

public class CustomIndex : Sitecore.Data.Indexing.Index
{
    public CustomIndex(string indexName): base(indexName) {}

    protected override void AddFields(Item item, Document document)
    {
        //is item a sub-item (promo item)
        if (...)
        {
            //delete the sub-item lucene doc
            DeleteDoc(document); //is this possible or needed?

            //get parent item
            Item parentItem = item.Parent;

            //get lucene document for parent item
            Document parentDoc = GetParentDoc();

            //add fields to parent item lucene document
            parentDoc.Add(...);
            parentDoc.Add(...);
        }
        else
        {
            base.AddFields(item, document);
        }
    }
}

Answer 1

yes i agree, option #2 is better – index the children when you’re at the parent. mainly because you aren’t guaranteed what order the traversal will happen in, so the document may get re-created as you said.