Установка и интеграция solr с django под Ubuntu 12.04

[@DmitryTsepelev]

У вас не возникло проблемы с индексом связанных сущностей? Пример: есть Клиент, у него есть Менеджер, необходимо искать полнотекстовым поиском клиентов по имени менеджера, при изменении имени менеджера в индексе клиентов данные уже неактуальны.

[@PukeCloud]

Нет, у нас таких проблем пока не возникало. Тут все зависит от структуры самих индексов и переиндексации. Можно при обновлении объекта обновлять все индексы, где он участвует. Но это уже все специфика каждого конкретного проекта.

[@iroln]

На правах оффтопа:

Может вы знаете, почему могут возникать такие проблемы?
github.com/rtfd/readthedocs.org/issues/827

До разработчиков не достучаться, а мне нужно настроить поиск для локального сервера документации. В Django не силён, куда копать уже не знаю. Подразумеваю, что проблема с моделью для построения индекса, но не уверен, так как по коду вроде всё правильно.

[@PukeCloud]

Если честно, то я RTD не пользовался никогда, поэтому сложно сказать.

Судя по виду индекса и сообщению в ошибке проблемы возникают из-за того, что в индексе прописано поле slug related объекта version, а самого привязанного объекта не существует:

version = CharField(model_attr='version__slug', faceted=True)

Проверьте, что у всех объектов ImportedFile есть связанные объекты version. Через shell может выглядеть так:

files = ImportFiles.objects.filter(version__isnull=True)

[@iroln]

Спасибо за совет! Обязательно проверю.

[@PukeCloud]

Прошу прощения, не успел поправить опечатку: не ImportFiles, а ImportFile.

P.S.: предварительно импортировать эту модель надо, конечно же

[@deniszh]

После обновления любого из конфигов необходимо ребутать solr, чтобы изменения вступили в силу.

Это в общем случае неверно.
В solr естъ такие сущности как Cores — wiki.apache.org/solr/CoreAdmin — если изменения в конфигах обратно совместимы ядро можно перегрузитъ командой RELOAD.
Если же изменения несовместимы можно создать новое ядро через CREATE и «свапнутъ» его с текущим через SWAP.

[@PukeCloud]

Действительно, был не прав.
Спасибо за исправление, сейчас добавлю в пост.

[@gotlium]

У django-sphinx есть множество форков, которые работают с dj1.4+. Например этот.
Меня больше смущает другой вопрос: Почему вы не используете к примеру Real-time indexes?
В IT не принято подкидывать монетку при выборе стека. Нужно как минимум аргументировать и взвесить все варианты разумно.
1. В данной статье нет замеров производительности, нет реальных доводов, кроме тех, что официальная батарейка не работает.
2. Темная магия — это плохо. Зачем когда есть CheckInstall ну и dpkg build?

[@PukeCloud]

После django-sphinx захотелось чего-нибудь с бОльшим community.
Чем наш вариант отличается от Real-time indexes? В haystack это реализовано ровно так, как у нас, только мы еще в асинхрон это вынесли.
Это был не выбор стека, а выбор одного компонента. Когда у вас ограниченное количество времени на проект, то кроме монетки ничего не остается.
1. Замеров нет, но я не понимаю как они связаны с темой статьи. Не понял о какой вы батарейке. Генератор конфигов sphinx'а в django-sphinx или backend для xapian?
2. Согласен, что плохо. Есть масса вариантов лучше. Но в данном контексте они нам не нужны. Чтобы собирать всякие deb пакеты надо потратить больше времени, чем на этот простой скрипт, который целиком и полностью выполняет задачу. Плюсы «нормальной установки» в данной ситуации не ясны.

[@ur001]

О! Может вы мне ответите на этот вопрос о готовке ядер Solr-а? toster.ru/q/101767

С момента публикации вопроса ни одного ответа. Но за это время мне посоветовали перейти на ElasticSearch у которого конфиги на yaml/json, бинарник не требующий jre и другие плюшки.