Суть задачи:
На странице А есть форма ввода типа textarea с настраиваемым числом строк (от 1 до бесконечности)
Необходимо, чтобы друпал
1) последовательно сравнивал все строки из textarea (чтобы не искать идентичные строки)
2) производил поиск по значениям всех строк
3) выводил все найденые результаты одним списком (можно с разбивкой по страницам 1-2-3, можно без разбивки). Опционально - без дублирования (т.е. одну ноду два раза не выводить).
Т.е. некто Вася вводит в форму поиска 10 строк с разными значениями, друпал ищет все ноды с этими значениями и выводит их (со ссылками на соотв. ноды)
Вопросы
1) это вообще возможно?
2) есть ли модули с похожим функционалом (перерыл друпал.орг - не нашел)
3) насколько вообще это сложно реализуется?
спасибо
Комментарии
Забыл добавить - искать надо только в определенном типе контента
1) Возможно
2) хз
3) Несложно, можно даже модуль не писать, а сделать страницу с php-кодом, использующим функцию do_search. С пролистыванием и удалением дубликатов возможно придется попариться.
1)да
2) в стандартных не найдете. закажите сниппет у кого-нибуть с этого сайта.
3) не очень сложно
А сколько такая радость (грамотно написанная) может стоить?
часа 2-4 работы.
в зависимости от уровня от 500-1000 в час.
Итог: от 1000 до 4000.
Это шутка? Или вы забыли сказать что модуль еще будет варить кофе и жарить яичницу?
dev13 шутник
RxB, угу. При том шутит он неудачно на мой взгляд.
Я только для своего форума заказывал больше десятка весьма функциональных модов (ipb), и более 120 скриптов на php разного уровня сложности (обработка файлов, парсинг поисковиков и сервисов, системные утилиты и т.д.). Всё это было в стопицот раз заведомо сложнее и стоило максимум по моему 150 баксов.
вот часть тулзов http://4seo.biz/tools/
в среднем мне 1 скрипт выходил в районе 30-40 долларов (если тупо взять их полную стоимость и поделить на количество)
Вот после этого я и спрашиваю - оно кофе варить будет за такую цену?
Да я собственно против цены особо ничего не имею, но геморой разработчику модуля обеспечен, и этот геморой точно не решить в 4 часа
Ну я возможно чего-то не понимаю именно в друпале? В чем геморой?
Первое весьма не сложно реализуется на php, второе как мне видится - просто последовательные поиски в базе по ноде определенного типа. В чем тут могут быть большие сложности?
Я правда не понимаю. Поясните
если это выглядит простым, то это сложно
если это выглядит сложным, это нерешаемая проблема
законы Мерфи работают всегда;)
Цена - вещь относительная. кто то и работать за 4000 не будет=)
Уважаемый, я еще раз напоминаю что заказывал уже не одну сотню php скриптов и модов разной степени сложности. На некоторые ТЗ составляло порядка 30 листов (правда с описанием структуры базы, скриншотами и т.п.)
Это не понты, это к тому что я какбэ в курсе рынка разработок и цен на нём.
Друпал система с высоким порогом вхождения, это мне понятно. Но так нагло набивать цену на примитивные вещи - просто хамство.
Если каждый чих для друпала будет стоить сто баксов - проще заказать то что мне нужно с полным функционалом за 100-150. А нужно мне, как ни странно, не так уж и много.
Я понимаю вашу ремарку что некоторые и за 4000 работать не будут. Я тоже не делаю непрофильные вещи. Ни за какую цену.
Про законы мерфи - также из области понтов и надувания цены, ага. Этак можно договориться до того, что "хелло ворлд" задача слишком сложная, а потому не стоит и браться.
Я не зря попросил разъяснить, в чем заключается сложность. Пока этого нету - считаю вашу цену абсурдной. Хотя бы потому, что я уже видел что в друпале могут снипеты
А ежели появится список сложностей - вот тогда и поговорим, и может я и сам тогда решу что 4000 - золотая цена и надо срочно заказывать. И закажу. Люблю я это дело. Заказывать.
Извините за резкий тон, ежели что.
Вывести всё на одной странице - не проблема. В цикле несколько do_search (функция модуля search) и всё, элементарно. А если надо с пролистыванием и удалением дубликатов, которые бы было не тормозным, то тут думать надо)
Фактически нужно выполнить поисковый запрос вида (A and or (C and D) or E or (X and Y and Z). Но search вроде такого не поддерживает - или and или or, но не такие сложные запросы. Думаю это заложено в структуре индекса. Поэтому надо выполнять отдельные запросы вида A and B, потом объединять, удалять дубликаты и потом может в кэш поместить, чтобы пролистывание быстрым было. Но не очевиден итоговый размер этого кэша… Если тысячи нод на сайте, то первый поиск может сильно тормозить.
Поэтому я пока только вижу дубовый метод, который будет тормозить на больших сайтах, или нужно вообще переписывать search с более продвинутым индексом, может подойдет mysql fulltext-индекс.
На самом деле в вашем топике нет формализации задания
Поиск вещь такая, сама в себе ...
По вашей задаче ...
1. Где, кто и когда определяет количество строк поиска и тип материала для поиска ? и бесконечность все таки достаточно не
определенная вещь
2. Что за поиск "точное совпадение","вхождение в более длинные слова", "точное совпадение фраз","перевод в траслит","Регистрозависимость","Глубина поиска","Релативность","Порядок выдачи результатов (критерий сортировки)" и т.д.
и т.п.
3. Как должен быть представлен результат: предполагается ли "шаблонизация" и "пост-темизация",
Что должно быть в выводе (тезус,вся нода, фрагмент ноды с найденным фрагментом,заголовок ноды)
4. На каком объеме данных это должно работать и приемлемое время отклика, нужно ли кэширование результатов поиска ?
...
Вот после ответов на эти вопросы, можно будет примерно посчитать объем работы и соответственно стоимость .... но сразу скажу что это будет гораздо больше 3-5 чел./часов (с учетом того, что это будет достаточно качественное решение)
вот и считайте
(для справки - например мой чел./ч. по факту стоит ~$28
при этом я не претендую на решение вашей проблемы
кто вас читать учил?
где в моих словах предложение услуг?
хехе. да я как раз и за 4000 не взялся бы=)
про законы мерфи: речи о хелло ворд не было. Трактовка - мрак.
Опять повторюсь: услуг я не предлагал. Ответил человеку о стоимости. С Вашей стороны было бы компетентно предложить свое видение стоимости и сложности, а не нести бред.
Понты? госпади сколько Вам лет
dev13, уйдите пожалуйста из моего топика, ок? Конкретно лично вам тут не рады Троллить предлагаю где-нибуть в другом месте. Я повелся на тролля и покормил его, впредь постараюсь таких ошибок не делать.
edhel, а если поиск будет осуществляться выборкой четко по дополнительным полям ноды с небольшой длиной? Ну например добавляем к ноде поля текстовые nick + icq + url и в них ищем, это упростит задачу и облегчит нагрузку на хост на ваш взгляд?
И кстати, работа через текстовый tmp-файл на хосте ускорит работу, как думаете? Ну если туда скидывать итерации по каждому из запросов (все ноды по каждой из строк запроса), а потом урлы нодов проверять на дублирование, читая из файла?
olk, спасибо за подсказки по формализации. Изначально вопрос был достаточно абстрактный, я сам над ним только начинал думать, создав топик.
1) Только администратор сайта (1 человек). Скажем max не более 50 строк (просто чтобы не начали парсить выборки). Ну т.е. задать можно будет хоть 10000, но врядли когда-то даже к 50 приблизимся в разрешенной глубине.
2)
- точное совпадение фраз + точное вхождение в более длинную фразу (поиск по a132 должен выдать запись со строкой zxa132mmt)
- регистронезависимость
- глубина - все ноды определенного типа
- релевантность - не имеет значения. Есть вхождение - есть в результатах поиска
- порядок выдачи результатов - сначала всё найденое для первой строки, потом всё найденое для второй и т.д.
- чистку от дублей имхо есть смысл сделать через temp-файл со случайным hash-именем (чтобы при 2 одновременных запросах небыло конфликта), про это чуть выше написал
3) лист со списком ссылок на ноды. Текст ссылки на ноду=тексту по которому нода найдена (урл, или номер аськи например, или ник), чтобы юзер видел что именно в базе нашлось. В случае нахождения одной ноды по двум строкам - просто первую из них
4) несколько тысяч нод (upto 10-15k я думаю, но по началу 2-3к)
Кеширование врядли пригодится, т.к. очень низка вероятность совпадения запроса (стремится к нулю)
Хост - в любом случае или вдс или дедик, с этим никаких проблем. При том в случае посещаемости хотя бы в 300 уников в сутки без труда возьму простенький дедик с гигом оперативы.
как мне видится это все можно реализовать минуя вообще модуль search, пользуясь запросами к базе и временными файлами. Или модуль серч на ваш взгляд решит эту задачу быстрее? Как я понимаю ему нельзя указывать, что в каком типе нод индексировать? (какие поля и в каких поиск вести)
Человекочасы это хорошо, но как показала практика заказов работы в офисе, на веблансере и фри-ланс - контролировать время исполнения реально только в офисе В остальных случаях обычно выставляется конечный ценник с учетом того, что и клиент и исполнитель максимально полно друг с другом обсудили детали
edhel, olk, спасибо за развитие мысли