Gravatar for

Question by Simon, Dec 13, 2016 3:12 PM

Deleting clone of item when item is deleted

This is a follow up of this question:

The answer was to create a clone of the children and attach this clone to another parent. This said, if I delete the original children in Sitecore, what would be the best approach to delete the clones? Will the post item processing pipeline also process items to be deleted?

1 Reply
Gravatar for

Answer by Luc Bergeron, Dec 14, 2016 2:04 PM

I would try to register an event handler on the item:deleting event. This way, it would be possible to delete all the item clones before the actual item is deleted.

I don't think the post processing pipeline would be of any use in this case.


Gravatar for

Comment by rloeb, Dec 14, 2016 2:32 PM

Taking a step back, when we were talking about clones, I assumed I'm injecting a clone into Coveo but not Sitecore. So when I tap into the item:deleting event of the parent Sitecore Item, I assume there needs to be some code in the pipeline that tells Coveo to also delete the clones from Coveo (which presumably have some kind of UniqueID or some other property by which they're referenced in Coveo), is there a code sample for this? I'd assume we need to tell Coveo which clones to delete?

Let me know if I understood correctly or else maybe you meant we need to clone our Items in Sitecore, i.e. create clone Items.

As a side note, I've noticed that Coveo seems to have some kind of concept of "Attachments" it uses for .zip files and also some MS Office documents that have documents embedded in them. Might this be leveraged in some way? (Just thinking out loud)

Gravatar for

Comment by Luc Bergeron, Dec 14, 2016 3:34 PM

@rloeb, thanks for the precisions, you are right. Given the clones are Coveo documents (not Sitecore item clones), you will need to tell Coveo which documents to delete.

I guess that the custom logic that clones the Coveo documents could be reused in the event handler to retrieve the list of Document URIs to delete based on the item being deleted.

Then, you retrieve the search index instance and call the Delete method for each cloned document.

The whole sample looks like this:

var index = Sitecore.ContentSearch.ContentSearchManager.GetIndex("Coveo_web_index") as Sitecore.ContentSearch.AbstractSearchIndex;

// Fill the list with all the document URIs to delete in Coveo.
List<string> documentsToDelete = new List<string>();

foreach (string documentUri in documentsToDelete) {
    var indexableId = new Sitecore.ContentSearch.IndexableId<string>(documentUri);


Gravatar for

Comment by rloeb, Dec 14, 2016 5:20 PM

How do you suggest reliably populating "documentsToDelete", given the information I would have about the true Sitecore Item (e.g. ID guid, uri, etc.).

Specifically, when I add the clone with this call from the sample code: (;jsessionid=9350A961401E2D2C5D4CB1C8D1BEC425)

p_Args.OutputItems.Add(new SitecoreIndexableItem(relatedMediaItem));

How can I later find what I just added, i.e. will it have the same _id=(Sitecore ID Guid) as the others? Or is there a better way?

Restated differently, it seems like basically I have to run a query to get the documentUri's of the clones, correct? And the best way would be search for all entries that have the same _id as the real SitecoreItem?

Also, what about edits to the master Sitecore item? Do I have to delete clones, add new ones? Or can they be edited "in place"?

Gravatar for

Comment by Luc Bergeron, Dec 15, 2016 10:15 AM

A very simplistic way of deleting clones is to rebuild the index. The rebuild takes care of deleting any document that is not part of the current indexing pass. This approach is not efficient, but it might be useful for very small indexes.

The clone URI depends on how you are defining the clones. The clone URI might or might not contain the master item ID. But the most important point is that a given clone always have the same URI. If the URI changes, the Coveo search index will see it as a new document.

I would advise against performing search queries from an event handler. It would work for sure but it may generate a huge amount of search queries which could impact the indexing performance and other search queries. You must keep in mind that those background search queries cannot be cached by the search index.

I guess it would be better to store a mapping of the clones URIs on the Sitecore side. When the master item is updated, the post item processing pipeline is invoked and the clones are defined. At this point it would be possible to store (in a Sitecore item or an external database) the URIs of the clones. The Coveo search index will determine (based on the document URI) whether the clone is a new document or an existing one. So editing the master item should not be a problem. The clones are added or updated every time. However, the deletion should be handled from Sitecore as the Coveo search index cannot know by itself that a clone has to be deleted. This is where the mapping is useful. After the clones are defined, you can check which clones were in the previous pass and should now be deleted. After that, you update the mapping with the up-to-date clones.

Gravatar for

Comment by rloeb, Dec 15, 2016 10:52 AM

Ah, I thought URI was something Coveo assigned. You're saying we create and manage our own unique URI scheme for clones, which I'm assuming can be any string?

Gravatar for

Comment by Luc Bergeron, Dec 16, 2016 9:12 AM

The clone URI can be any valid URI, as long as it does not contain a query string.

Ask a question