2011-11-24 8 views
6

SituaciónSitecore Lucene: re-índice de niño (o el padre) artículos sobre la actualización elemento

tengo el siguiente Sitecore Lucene config:

  • nuevo índice, type = "Sitecore.Search.Index , Sitecore.Kernel"
  • contiene dos rastreadores (una orugas personalizado que añade extra 'campos calculados')
  • Cada rastreador se encarga de su plantilla específica GUID, ya que contienen diferentes campos calculados

Problema

Los campos calculados se basan en padre/hijo campos. La forma en que Lucene en Sitecore parece estar configurado, es que solo los documentos para los artículos que en realidad fueron cambiados se actualizan en el índice.

Como tal, los campos calculados en otros documentos (que son obligatorios, existen condiciones de búsqueda en estos campos) no se actualizan.

Pregunta

¿Existe la posibilidad de activar manualmente la actualización de otros elementos en el índice?
He buscado heredar Sitecore.Search.Index, pero ninguno de los métodos relevantes son virtuales.

Además, traté de suscribirme a los eventos de indexación del proveedor:
evento público EventHandler OnRemoveItem;
evento público EventHandler OnRemoveVersion;
evento público EventHandler OnUpdateItem;

La idea detrás de esto era desencadenar OnUpdateItem-event en el DatabaseCrawler para otros elementos que necesitan actualizarse, pero no puede desencadenar este evento fuera de IndexingProvider.

¿Hay alguna manera de desencadenar una actualización de índice sin realizar una reconstrucción completa, que no implique guardar/volver a publicar esos otros elementos?

Gracias!
Sander

Respuesta

4

La actualización del índice se activa a través de la HistoryEngine, cuyos eventos y métodos son públicos, por lo que potencialmente podría utilizar un controlador de eventos en el motor de la historia de detectar cuando se produce un cambio que requiere indexación, y luego añadir entradas adicionales a la historia de los elementos padre/hijo que necesita reindexar también.

Sitecore.Data.Managers.IndexingManager.InitializeEventHandlers() tiene un ejemplo de conectar un controlador al HistoryEngine de las bases de datos.

Luego, su lógica de manipulador sería algo así como

protected void HistoryEngine_AddedEntry(object sender, HistoryAddedEventArgs e) 
{ 
    Item item = e.Database.GetItem(e.Entry.ItemId); 
    //TODO: Add logic to make sure e.Entry.ItemId requires a parent/child reindex as well 
    //TODO: Make sure that logic also prevents excessive or infinite recursion since we'll be triggering the AddedEntry event again below 
    Item parent = item.Parent; 
    //RegisterItemSaved doesn't appear to do anything with its second argument 
    e.Database.Engines.HistoryEngine.RegisterItemSaved(parent, null); 
} 

El mejor lugar para colocar este es probablemente en la tubería initialize.

N. B. esta es una idea no probada, por favor, informe de nuevo en sus resultados!

+0

¿No disparará el HistoryEngine con entradas adicionales que tenga algún efecto secundario adverso en otros componentes de Sitecore? Parece razonable, así que lo intentaré pronto. Volveré a informar pronto, primero necesito terminar algunas otras tareas de sprint;) – sanderd

+1

El análisis en el reflector muestra a IndexingManager como el único oyente para HistoryEngine.AddedEntry, por lo que probablemente esté a salvo allí. No puedo garantizar si es a prueba de futuro en ese sentido, supongo. Dicho esto, muestra un punto que su oyente de AddedEntry necesita tener lógica para prevenir la recursión infinita. Editaré – techphoria414

Cuestiones relacionadas