Comments 11
У вас не возникло проблемы с индексом связанных сущностей? Пример: есть Клиент, у него есть Менеджер, необходимо искать полнотекстовым поиском клиентов по имени менеджера, при изменении имени менеджера в индексе клиентов данные уже неактуальны.
На правах оффтопа:
Может вы знаете, почему могут возникать такие проблемы?
github.com/rtfd/readthedocs.org/issues/827
До разработчиков не достучаться, а мне нужно настроить поиск для локального сервера документации. В Django не силён, куда копать уже не знаю. Подразумеваю, что проблема с моделью для построения индекса, но не уверен, так как по коду вроде всё правильно.
Может вы знаете, почему могут возникать такие проблемы?
github.com/rtfd/readthedocs.org/issues/827
До разработчиков не достучаться, а мне нужно настроить поиск для локального сервера документации. В Django не силён, куда копать уже не знаю. Подразумеваю, что проблема с моделью для построения индекса, но не уверен, так как по коду вроде всё правильно.
Если честно, то я RTD не пользовался никогда, поэтому сложно сказать.
Судя по виду индекса и сообщению в ошибке проблемы возникают из-за того, что в индексе прописано поле slug related объекта version, а самого привязанного объекта не существует:
Проверьте, что у всех объектов ImportedFile есть связанные объекты version. Через shell может выглядеть так:
Судя по виду индекса и сообщению в ошибке проблемы возникают из-за того, что в индексе прописано поле slug related объекта version, а самого привязанного объекта не существует:
version = CharField(model_attr='version__slug', faceted=True)
Проверьте, что у всех объектов ImportedFile есть связанные объекты version. Через shell может выглядеть так:
files = ImportFiles.objects.filter(version__isnull=True)
После обновления любого из конфигов необходимо ребутать solr, чтобы изменения вступили в силу.
Это в общем случае неверно.
В solr естъ такие сущности как Cores — wiki.apache.org/solr/CoreAdmin — если изменения в конфигах обратно совместимы ядро можно перегрузитъ командой RELOAD.
Если же изменения несовместимы можно создать новое ядро через CREATE и «свапнутъ» его с текущим через SWAP.
У django-sphinx есть множество форков, которые работают с dj1.4+. Например этот.
Меня больше смущает другой вопрос: Почему вы не используете к примеру Real-time indexes?
В IT не принято подкидывать монетку при выборе стека. Нужно как минимум аргументировать и взвесить все варианты разумно.
1. В данной статье нет замеров производительности, нет реальных доводов, кроме тех, что официальная батарейка не работает.
2. Темная магия — это плохо. Зачем когда есть CheckInstall ну и dpkg build?
Меня больше смущает другой вопрос: Почему вы не используете к примеру Real-time indexes?
В IT не принято подкидывать монетку при выборе стека. Нужно как минимум аргументировать и взвесить все варианты разумно.
1. В данной статье нет замеров производительности, нет реальных доводов, кроме тех, что официальная батарейка не работает.
2. Темная магия — это плохо. Зачем когда есть CheckInstall ну и dpkg build?
После django-sphinx захотелось чего-нибудь с бОльшим community.
Чем наш вариант отличается от Real-time indexes? В haystack это реализовано ровно так, как у нас, только мы еще в асинхрон это вынесли.
Это был не выбор стека, а выбор одного компонента. Когда у вас ограниченное количество времени на проект, то кроме монетки ничего не остается.
1. Замеров нет, но я не понимаю как они связаны с темой статьи. Не понял о какой вы батарейке. Генератор конфигов sphinx'а в django-sphinx или backend для xapian?
2. Согласен, что плохо. Есть масса вариантов лучше. Но в данном контексте они нам не нужны. Чтобы собирать всякие deb пакеты надо потратить больше времени, чем на этот простой скрипт, который целиком и полностью выполняет задачу. Плюсы «нормальной установки» в данной ситуации не ясны.
Чем наш вариант отличается от Real-time indexes? В haystack это реализовано ровно так, как у нас, только мы еще в асинхрон это вынесли.
Это был не выбор стека, а выбор одного компонента. Когда у вас ограниченное количество времени на проект, то кроме монетки ничего не остается.
1. Замеров нет, но я не понимаю как они связаны с темой статьи. Не понял о какой вы батарейке. Генератор конфигов sphinx'а в django-sphinx или backend для xapian?
2. Согласен, что плохо. Есть масса вариантов лучше. Но в данном контексте они нам не нужны. Чтобы собирать всякие deb пакеты надо потратить больше времени, чем на этот простой скрипт, который целиком и полностью выполняет задачу. Плюсы «нормальной установки» в данной ситуации не ясны.
О! Может вы мне ответите на этот вопрос о готовке ядер Solr-а? toster.ru/q/101767
С момента публикации вопроса ни одного ответа. Но за это время мне посоветовали перейти на ElasticSearch у которого конфиги на yaml/json, бинарник не требующий jre и другие плюшки.
С момента публикации вопроса ни одного ответа. Но за это время мне посоветовали перейти на ElasticSearch у которого конфиги на yaml/json, бинарник не требующий jre и другие плюшки.
Sign up to leave a comment.
Установка и интеграция solr с django под Ubuntu 12.04