Ну, вообще говоря, всякие абстрагирующие прокси типа haystack это прикольно, наверное; но я лично больше верю в родные специализированные решения на своем месте, чем кучи абстракций.
Те. считаю, задачу «давайте легко прикрутим поиск к фреймворку X» в идеальном мире должен хорошо решать вообще тот или иной наш нативный интерфейс; следующее допустимое приближение это родной плагин (видимо, это django-sphinx или любой его живенький форк); и только затем обобщенные абстракции типа haystack.
Причем мы ж завсегда готовы работать с авторами подобных штук; пишите письма; обсудим, поможем, приделаем. Однако если обстоятельный комментарий «почему нет» написать человек находит время, а тупо кинуть мне ссылку уже нет, то ничего конструктивного не произойдет, очевидно. Это как бы «намек» желающим форкнуть, доработать итп.
А, речь перескочила на группировку по строковым атрибутам (колонкам), что ли? Да, там должно вернуть некий непонятный внутренний группировочный ключ. Однако сам *атрибут* при этом должен быть вполне корректным.
> К сожалению я не нашел способа делать группировку для MVA атрибутов, например, если статья содержит тег 1, а вторая 1&2, то мы получим такой результат: {1: 1, (1, 2): 1}, вместо {1: 2, 2: 1}
Группировка по MVA есть и работает. Если документ принадлежит N группам, он во все N и попадет, все агрегатные функции посчитаются правильно.
Другое дело, что в каждой группе выбирается ровно 1 представитель группы, SQL style. Расширения для выбора M представителей группы пока нет. (Есть, вроде, древний запрос в багтрекере про это даже.) Беда в этом?
Пока никак, только сконвертировать в список номеров, действительно. Solr умеет? Где почитать (я плохо ориентируюсь в их документации)? Ну и заодно, наверное про его актуальный набор поддерживаемых сегодня типов где почитать?
Правильно ли я понимаю, что если добавить в API новый метод FacetQuery с одним дополнительным параметром (список атрибутов, по которым нужна группировка) — то в Сфинксе, с вашей точки зрения, немедленно «появится» труевая поддержка «фасеточного поиска»?
Парням из haystack достаточно было тупо написать мне письмо, и получить официальное разрешение использовать клиентскую библиотеку. Напишу-ка я им сам, раз они стеснительные.
Про варианты. Есть еще один: можно ходить напрямую в Sphinx через SphinxQL, все будет совершенно аналогично работе с обычным MySQL.
Про режимы поиска. Они, может, некоторые мелочи слегка упрощают, но это таки легаси. Я бы советовал таки везде приводиться к MATCH_EXTENDED.
Про релизы. Мы обратно совместимы, практически всегда. Ну те. любая новая версия обязана работать с любыми старыми клиентами и умеренно старыми форматами индексов.
Те. считаю, задачу «давайте легко прикрутим поиск к фреймворку X» в идеальном мире должен хорошо решать вообще тот или иной наш нативный интерфейс; следующее допустимое приближение это родной плагин (видимо, это django-sphinx или любой его живенький форк); и только затем обобщенные абстракции типа haystack.
Причем мы ж завсегда готовы работать с авторами подобных штук; пишите письма; обсудим, поможем, приделаем. Однако если обстоятельный комментарий «почему нет» написать человек находит время, а тупо кинуть мне ссылку уже нет, то ничего конструктивного не произойдет, очевидно. Это как бы «намек» желающим форкнуть, доработать итп.
Плюс тот факт, что я с Д. в итоге ведь связался почтой и *раньше*, чем появился комментарий, усиляет мою веру в человечество!!!
Большая часть т.н. «минусов» вызывает у меня сильное офигение.
Впрочем, я давно убедился, что документацию никто не читает, зато в сложившиеся каким-то образом мифы верят многие.
Сейчас напишу ему туда.
Группировка по MVA есть и работает. Если документ принадлежит N группам, он во все N и попадет, все агрегатные функции посчитаются правильно.
Другое дело, что в каждой группе выбирается ровно 1 представитель группы, SQL style. Расширения для выбора M представителей группы пока нет. (Есть, вроде, древний запрос в багтрекере про это даже.) Беда в этом?
Смотрю, миф конкретно прилип.
Про режимы поиска. Они, может, некоторые мелочи слегка упрощают, но это таки легаси. Я бы советовал таки везде приводиться к MATCH_EXTENDED.
Про релизы. Мы обратно совместимы, практически всегда. Ну те. любая новая версия обязана работать с любыми старыми клиентами и умеренно старыми форматами индексов.
В первом грубом приближении — кнопка один из факторов, влияющих на создание несколько неправильного имиджа проекта/компании, что ли.
Речь изначально шла про донейты от частных лиц, поэтому беды бухгалтерии, тем более с русской спецификой, нерелевантны.