Замена htdig

Можно ещё посмотреть DataparkSearch, http://www.dataparksearch.org/

Правда со стабильностью у него: кто жалуется, а у кого и нормально работает, как повезёт :)

Это для людей с дебаггером под мышкой, пардон за каламбур.

Ну это слишком преувеличено :)

Я так и не нашел ни одного mysql сервера старше версии 4.0.7, имеющего такие же проблемы с LIMIT OFFSET как у вас. Может оно всё у вас с дебаггером под мышкой ? :d

Абсолютно не преувеличенно. У вас работает поиск в пределах одного сайта? Лично у меня не работал, пока не поправил (фактически дописать пришлось код). В mod_dpsearch результаты двоятся. stored в некоторые моменты своей жизни начинает сжирать 100% процессорного времени. если слеш не поставил в конце урла вида http://rbc.ru тоже проблемы с группировкой по сайту. Впрчем, я одному из авторов послал описания проблем, надеюсь в будущем это поправят.

А сколько там всего еще скрытого есть? Это то, на что я непосредственно напоролся. Я уж молчу про то, что процесс конфигурации не нашел либы mysql, но не обломился с соответствующими словами. Зато потом обламывалась компиляция. И уж про такую мелочь, что VarDir в случае его нестандартного расположения надо прописать в search.htm.

Большинство ваших проблем обсуждалось на форуме проекта. В частности, удвоение результатов при использовании mod_dpsearch зачастую связано с неправильной конфигурацией (ведь у нас не принято читать документацию, правда ? :), и проблемы с нестандартным расположением mysql и прочих используемых библиотек просто решаются явным указанием путей к ним при запуске configure. Ну и естественно, что нестандартную VarDir нужно указывать явно, хотя можно поменять и при сборке, опять же указав опцию для configure.

Понимаете ли в чем дело. Документацию я как раз читал. Кроме стандартной документации есть еще всякие интересные факи к ней!!! Ссылки на которые не сразу находишь. Хотя было бы гораздо логичнее включить это все в документацию. Понимаю руки не доходя.

Кроме того, вот что например говорит сам Максим по поводу VarDir http://www.dataparksearch.org/cgi-bin/simpleforum.cgi?fid=02&topic_id=1080812470

То есть получается он сам не знает, что VarDir можно задавать в search.htm?

И объясните, плз, каким образом неправильная конфигруация может привести к ДУБЛИРОВАНИЮ результатов. К отсутствию результатов, я еще могу понять, но вот к ДУБЛИРОВАНИЮ сомнительно. Где, кстати, про это написано в форуме? Покажите пальцем. Насколько я заметил форум не умеет искать по-русски. По-английски я ничего не нашел похожего. Зато я нашел в форуме описание проблемы с поиском внутри сайта! И никакого внятного ответа на эту тему. Кроме предложения попробовать версию 4.31. Но сейчас 4.38 и проблема до сих пор есть.

Потом опять-таки есть неприятные всякие моменты в стандартных dist-конфигах. Там есть параметр, который должен быть одинаковый во всех конфиг файлах. Но в одном файле мне предлагают раскомментировать значение 1024, а в другом (там неявное значение) получается 768? Что это параноя? Конечно, в документации про это написано, но ради таких простых вещей человек не должен лезть в доки.

это все неестественно до тех пор, пока в доках не написано. заметьте именно в доках по search.htm, а не где-нибудь на форуме, где нельзя искать по-русски. И потом, заметьте, я не ругаю. Для того количества разработчиков, которые этим всем занимаются может даже замечательно. Просто вместо безосновательного восхищения я говорю правду: все-таки надо уметь работать в дебаггере и знать язык Си, если хочешь быть уверен, что все поставится и заработает так, как надо.

В приведённом вами топике форума говорится о проблеме создания .pid файла в недефолтной VarDir для демона searchd и способе указания этой VarDir так, чтобы .pid файл создавался именно там, где надо.

Действительно, поиск по форуму какой-то глючный, с ходу ту ветку найти не удалось, но суть в том, что для mod_dpsearch DBAddr нужно только в одном кофигурационном файле, а не в каждом, т.е. если указать в двух конфигурационных файлах, то результаты удвоятся, если в трёх - утроятся.

По-моему, не дебаггер нужен, а правильно задавать вопросы на форуме :)

ну в этом случае может форум меня бы и спас, если бы у меня было время ждать ответа с форума, но он явно не спас бы меня в случае трех других описанных баг, которые явно конфигурацией не лечатся. хорошо, двух, если Вы считаете, что mysql всегда правильный и правильной версии.

Вот опять-таки, не буду говорить, что в mnogosearch или htdig лучше и что у инх таких проблем нет. Просто констатирую факт.