Каталоги Twin Lucene index после обновления Nhibernate. Поиск - PullRequest
1 голос
/ 11 января 2010

Я был занят обновлением нашего стека n * до более новой версии. Мы использовали FluentNhibernate для конфигурации и Nhibernate.search вместе с Lucene.Net для полнотекстового поиска. Все работало нормально, пока я не изменил различные версии библиотек на следующие:

  • FluentNHibernate.dll: 1.0.0.593
  • NHibernate.dll: 2.1.0.4000
  • NHibernate.Search.dll: 2.0.0.1001
  • Lucene.Net.dll: 2.3.1.3

Стек работал как раньше, но я заметил кое-что странное; тогда как раньше каталог индекса Lucene содержал по одному подкаталогу для каждого индексированного класса, теперь он использует две подкаталоги с суффиксом целого числа.

Мы пошли от

LuceneDirectory
.Class1
.Class2

до

LuceneDirectory
.Class1.0
.Class1.1
.Class2.0
.Class2.1

Я немного осмотрел здание конфигурации FluentNhibernate и обнаружил, что для каждого сопоставления у меня создано два импорта, один с полным именем сопоставленного класса, один без (если я сопоставляю класс "Пользователь", я будет иметь одно сопоставление и два импорта "POCOAssembly.User" и "User"). Каталоги создаются при вызове Initialize FullTextIndexEventListener.

Кто-нибудь сталкивался с такой же проблемой? я прочитал заметки о выпуске nhibernate.search, но не нашел никакой информации об изменении отображений; есть что-то, что я пропускаю? Произошло ли критическое изменение в библиотеках?


Редактировать

Я понял, что может быть важно указать, что мои сопоставленные классы и мои сопоставления происходят из общего базового объекта, используемого для целей аудита (дата создания / время обновления).

1 Ответ

1 голос
/ 11 января 2010

Я обнаружил, что о проблеме сообщалось в NHibernate JIRA: https://nhibernate.jira.com/browse/NHSR-22

Что произошло, так это то, что я установил два свойства по умолчанию в конфигурации NHibernate; "hibernate.search.default.directory_provider" и "hibernate.search.default.indexBase" Эти конфигурации по умолчанию считаются двумя осколками, поскольку код на данный момент не тестировался.

Временное решение: удалить запись «hibernate.search.default.directory_provider», поскольку по умолчанию она верна.

...