2011-09-12 10 views
14

Tengo una pieza de software existente que está utilizando Lucene 2.2.x y necesito actualizar a 3.1. Para hacer esta actualización, he leído documentación que sugiere actualizar primero a 2.9.x, eliminar todas las advertencias de desaprobación y luego actualizar a 3.1.x. Tengo implementados índices existentes con los que necesito mantener el código compatible.Preguntas sobre la actualización de Lucene de 2.2 a 2.9 a 3.1

Mi pregunta principal se trata de manejar las fechas. En 2.2.x tuve que usar DateTools.dateToString() para convertir Date.getTime() en una cadena que podía indexar y almacenar. Creé dos campos en cada documento. Uno para la búsqueda que se almacenó con la resolución de la hora, y el otro campo que no fue analizado. Ahora Lucene 2.9.x es compatible con diferentes tipos de datos diferentes de cadenas. ¿Se pueden usar estos nuevos tipos en RangeQueries si está en contra de una versión anterior que utilizó DateTools para convertir fechas en cadenas? Aquí está el código que lo cambié demasiado:

Antes:

return new RangeFilter("dateArchived-stored", 
       DateTools.dateToString(start, DateTools.Resolution.MILLISECOND), 
       DateTools.dateToString(end, DateTools.Resolution.MILLISECOND), 
       false, true); 

Después:

return NumericRangeFilter.newLongRange("dateArchived-stored", 
             start.getTime(), 
             end.getTime(), true, true); 

Ahora que Lucene es compatible con los tipos de datos que no son cadenas hacen que necesitamos para estar preocupados con la resolución de fechas como lo hicimos con las consultas de Término?

IndexWriter requiere declarar un MaxFieldLimit. Las versiones anteriores no lo hicieron. ¿Está utilizando ILIMITADO el mismo comportamiento que en versiones anteriores? ¿Es más seguro usar ILIMITADO dado que hay índices que leeré que fueron creados con 2.2?

Antes:

new IndexWriter(indexDirectory, analyzer) 

Después:

new IndexWriter(FSDirectory.open(indexDirectory), analyzer, true, IndexWriter.MaxFieldLength.UNLIMITED) 

Clasificar objetos requiere una declaración SortField que requiere un tipo de ese campo. Para los campos existentes indexados con versiones 2.2.x, ¿podemos declarar los campos previamente indexados como Cadena a otro tipo, o deberían ser siempre SortField.STRING?

Antes:

new Sort("timestamp", false) 

Después:

new Sort(new SortField("timestamp", SortField.LONG, false)) 

es que esto funciona con índices creados en 2.2.x, pero leído por 2.9.x?

Finalmente, ¿tendré algún problema con ir directamente a 3.1.x con índices integrados en 2.2.x? Voy a hacer esta transición a 2.9.x en mi sistema de desarrollo local, pero en el campo irá de 2.2.x directamente a 3.1.x. ¿Tendré que lanzar una versión usando 2.9.x?

Respuesta

1

"Es más seguro usar UNLIMITED". sí. esa opción no tiene nada que ver con los documentos ya creados.

Si tiene campos de cadena, no puede usar el rango numérico en ellos. Puede verificar esto por su cuenta.

Cuestiones relacionadas