У меня есть существующее программное обеспечение, которое использует Lucene 2.2.x, и мне нужно обновить его до 3.1. Чтобы выполнить это обновление, я прочитал документацию, в которой предлагается сначала обновить до 2.9.x, удалив все предупреждения об устаревании, а затем обновить до 3.1.x. У меня развернуты существующие индексы, которые необходимы для обеспечения совместимости кода.
Мой главный вопрос касается обработки дат. В 2.2.x мне пришлось использовать DateTools.dateToString () для преобразования Date.getTime () в строку, которую я мог индексировать и хранить. Я создал два поля в каждом документе. Один для поиска, который был сохранен с часовым разрешением, а другое поле, которое не было проанализировано. Теперь Lucene 2.9.x поддерживает другие типы данных, отличные от string. Могут ли эти новые типы использоваться в RangeQueries, если это не относится к предыдущей версии, которая использовала DateTools для преобразования дат в строки? Вот код, который я тоже изменил:
До:
return new RangeFilter("dateArchived-stored",
DateTools.dateToString(start, DateTools.Resolution.MILLISECOND),
DateTools.dateToString(end, DateTools.Resolution.MILLISECOND),
false, true );
После того, как:
return NumericRangeFilter.newLongRange("dateArchived-stored",
start.getTime(),
end.getTime(), true, true );
Теперь, когда Lucene поддерживает нестроковые типы данных, нужно ли нам заботиться о разрешении дат, как мы это делали с запросами Term?
IndexWriter требует объявления MaxFieldLimit. Предыдущие версии не сделали. Использование UNLIMITED такое же поведение, как в предыдущих версиях? Безопаснее всего использовать UNLIMITED, учитывая, что я буду читать индексы, созданные с помощью 2.2?
До:
new IndexWriter( indexDirectory, analyzer )
После того, как:
new IndexWriter( FSDirectory.open(indexDirectory), analyzer, true, IndexWriter.MaxFieldLength.UNLIMITED )
Для сортировки объектов требуется объявление SortField, в котором требуется тип этого поля. Для существующих полей, проиндексированных в версиях 2.2.x, мы можем объявить поля, ранее проиндексированные как String, для другого типа, или они всегда должны быть SortField.STRING?
До:
new Sort("timestamp", false )
После того, как:
new Sort(new SortField("timestamp", SortField.LONG, false) )
Будет ли это работать с индексами, встроенными в 2.2.x, но считанными с 2.9.x?
Наконец, возникнут ли у меня проблемы с переходом на 3.1.x с индексами, встроенными в 2.2.x? Я собираюсь перейти на 2.9.x в моей локальной системе разработки, но в полевых условиях он будет переходить с 2.2.x прямо на 3.1.x. Должен ли я выпустить версию, использующую 2.9.x?