Решение, которое вы упомянули в ваш ответ , является правильным.
Другое решение будет иметь @IndexedEmbedded
от дочернего элемента к родителю, добавив @Facet
непосредственно к идентификатору родителя.и используйте parent.parentId
в качестве имени поля в своем запросе на фасетирование, как показано в PR, который я только что отправил .
Основное преимущество вашего решения заключается в том, что если Parent
сам индексируется (если он имеет собственный индекс), родительский индекс не будет излишне загрязнен ограненным полем (в отличие от моего решения).
Главный недостаток вашего решения заключается в том, что вы по существуобъявите индексированное поле для переходного поля в вашей сущности (переходное в смысле JPA, т.е. не сопоставлено непосредственно со столбцом базы данных).Это означает, что Hibernate Search не может определить, когда изменится это значение, и в результате Hibernate Search отключит некоторые оптимизации и будет переиндексировать сущность Child
всякий раз, когда изменяется свойство Child
, любое свойство , даже не связанные.Если ваша сущность мала, редко обновляется или имеет ограниченное количество экземпляров, это может не иметь значения.Просто имейте это в виду, если вы заметите много чтений из базы данных, по-видимому, без причины в будущем.