0002758: Поиск в метках по нескольким параметрам

Notes
(0016076) vasketsov (manager) 25-06-2015 09:52	>поиска по нескольким ключевым словам Как Вы себе представляете это чисто с точки зрения пользовательского интерфейса?

(0016077) stepanxxx (reporter) 25-06-2015 11:07	Если без изменения интерфейса, то предлагаю ввести некий символ разделитель в строке поиска по меткам. Например, строка "ул. Ленина"<символ разделитель>"д.35" интерпретировалась бы в два операнда соединенных логическим И или логическим ИЛИ(выбор, логического оператора из выпадающего списка или через RadioButton, например). Просто есть необходимость поиска меток с названием определенной улицы(имеется в описании) и также имеющейся в описании метки названия фирмы. Т.е. найти все метки по такой-то улице, принадлежащей такой-то фирме. Как я понимаю на данный момент поиск в метках не поддерживает никакого синтаксиса поиска и понимает текст просто "как есть"?

(0016078) vasketsov (manager) 25-06-2015 17:55 edited on: 25-06-2015 18:01	>поиск в метках не поддерживает никакого синтаксиса поиска Почти так. Если метки хранятся в SML, то средства поиска SQL недоступны, и поиск по строке (имени метки или описания) просто проверяет наличие указанной строки в имени (описании) метки. Возможный вариант сделать более крутой поиск - это поиск через регулярные выражения, пока этого нет. Если же доступны возможности SQL (например, в SACS можно хранить метки в SQLite уже давно, в основной версии программы судя по всему скоро появится также SQLite в простом виде, в SACS планируется хранение меток во взрослых СУБД), то тогда можно использовать LIKE (а для некоторых СУБД - и регулярные выражения тоже). Про регулярные выражения писать не буду, напишу про LIKE. LIKE - намного более мощный способ поиска (по сравнению с проверкой вхождения строки в имя метки, как сделано для SML), прежде всего потому что позволяет использовать два специальных метасимвола % и _ для замены на любое количество любых символов и один любой символ соответственно (вопросы реализации русскоязычного поиска пока что оставим за рамками темы, это лишь иллюстрация, все совпадения случайны): а) WHERE name like '%здец' - вообще всё что заканчивается на 'здец' ; б) WHERE name like 'п_п' - это и 'пуп' и 'поп', но не 'пп' и не 'потоп'; в) WHERE name like '_о%' - это все слова от 2 и более букв, где вторая - о ('бо', 'бок', но не 'клоп' и не 'ор'); г) WHERE name like '_$_%' escape '$' - это все слова от 2 и более букв, где вторым идёт символ подчёркивания (после экранирующего символа он трактуется как обычный, а не как метасимвол). Ну и т.п. >поиска меток с названием определенной улицы(имеется в описании) и также имеющейся в описании метки названия фирмы То есть, требуется: а) для SQL либо descript like '%улица%фирма%' и при этом чтобы порядок был именно такой, либо descript like '%улица%' and descript like '%фирма%' и порядок неважен; б) для SML (регулярные выражения не прикручены) только descript contains 'улица' and descript contains 'фирма' ? зы. здесь contains просто аналог для наглядности, функция вызывается несколько иначе, но здесь это не принципиально. Если требуется именно это, что я подозреваю, то никто не пойдёт на то, чтобы давать прямой доступ к полям и писать их названия в запросе поиска. Так что максимум - это писать что-то типа ул. Ленина & д.35, а после разблюдовки строки внутри собирать условие поиска исходя из возможностей движка. Добавлять две строки для поиска по одному полю лично мне кажется неумным, потому что тогда лучше сразу пять строк. И на & я бы особо не рассчитывал, возможно он где-то используется для формирования заголовка или описания меток, тогда его нельзя, намучаемся экранировать (типа 'code&13' & 'code&10', или чтобы code&13 работало не как code and 13, а как раньше). Короче, надо проверить основные источники данных для импорта меток (росреестр, формы поиска снимков, обновления сервисов, онлайновые сервисы импорта треков и т.п., файлы импорта из устройств), и взять вменяемый понятный символ для разделителя, который нигде не будет использоваться в таких источниках (причём не только в имени и описании метки, а вообще, потому что алгоритм импорта имени и описания может меняться). Либо сделать возможность его настройки. Подозреваю, что в таком виде больше шансов, что доработка сделается и будет работать и не усложнять жизнь.

(0016079) stepanxxx (reporter) 26-06-2015 10:09	>в SACS можно хранить метки в SQLite уже давно С SACS был не знаком. Сегодня ознакомился и благополучно перевел все метки в SQLite. Ищет прекрасно, спасибо. По сабжу, если найдутся пользователи упорно желающие продолжать работать с sml, то вариант с настраиваемым символом разделителем мне кажется наиболее реальным решением. Но это теперь так, как предложение на долгосрочную перспективу. Собственно, остается вторая часть вопроса: 1) Вывод количества найденных меток в результатах поиска. С точки зрения интерфейса предлагаю добавить в результатах поиска строку "Найдено меток: <количество>". Большие массивы меток вручную посчитать довольно проблематично, а необходимость делать это для отчетности есть. 2) Возможность оставить отображаемыми только найденные метки со своими иконками. Добавить туда же в результаты поиска, например, чекбокс "отобразить только найденные метки". Смысл в том, что результаты поиска в данный момент отмечаются абстрактными кружками. А метки при этом либо остаются включенными, либо так же в полном составе отключенными. Чтобы оставить только нужные, нужно будет заходить в управление, поочередно отключать категории, и отдельные метки. Есть ли возможность реализации такого отображения нажатием одного функционального элемента? В нашем случае иконки меток обозначают тип объекта. Поэтому есть необходимость такой визуализации. З.Ы. Я так полагаю, что тикет теперь относится и к SACS.

(0016080) vasketsov (manager) 26-06-2015 11:26	>Возможность оставить отображаемыми только найденные метки со своими иконками Пишу не со стационара, а через соту через прокси, с ноутом в лесу маньячу. Поэтому коротко. В SACS есть поддержка ссылок в SQLite. Она включается на второй закладке в форме Управления метками. После по ПКМ в правом списке в той же форме надо проверить, что при перетаскивании будут создаваться ссылки, а не копироваться метки. А потом перетащить всё что надо (результаты поиска) в отдельную папку (в левом дереве). Выкл всё, вкл её - вот и результат. Видимость ссылок - независимо от видимости меток. В SML ссылки не поддерживаются и вряд ли будут. В общем случае я допускаю возможность реализации отображения только найденных меток исходя из некоторого фильтра, ну чтобы слой меток сам фильтровался при отображении (в общих настройках программы сохранялась опция). Но вряд ли такое быстро появится. Зато такое будет работать для любого типа хранения меток.

(0016081) zed (manager) 26-06-2015 18:17	> вопросы реализации русскоязычного поиска пока что оставим за рамками темы Почему же, очень интересный вопрос. Что делать с регистро-зависимостью поиска при использовании LIKE?

(0016083) vasketsov (manager) 29-06-2015 21:22	Нормальный регистронезависимый поиск на кирилице и вообще на UTF-8/16 делается перекрытием нескольких функций: The application can overload the built-in NOCASE collating sequence (using sqlite3_create_collation()) and the built-in like(), upper(), and lower() functions (using sqlite3_create_function())

(0016084) zed (manager) 30-06-2015 06:57	У тебя это сделано? В mORMot есть возможность переопределить NOCASE на виндозную CompareStringW, но посколько текст в базе хранится в UTF-8, а эта функция принимает UTF-16, то оно по всей видимости будет конвертировать строки туда-сюда и подтормаживать. И на сколько я понимаю, даже переопределив эти функции, регистронезависимость будет только для текущей локали пользователя?

(0016085) vasketsov (manager) 30-06-2015 08:56	>регистронезависимость будет только для текущей локали пользователя? База сама или в UTF-8 или в UTF-16. Что напишешь - то и будет. >текст в базе хранится в UTF-8 Может тебе попробовать базу сразу в UTF-16 создать? >сделано? Нет. У меня только sqlite3_collation_needed + sqlite3_create_collation (ревизия 881, файл Src/System/SQLite3Handler.pas и прочие в этой ревизии) сделано для сортировки версий (чтобы 3.99.0 < 3.101.0) Вот пример на хабре нашёлся http://habrahabr.ru/post/150543/ хотя когда я его смотрел, меня не покидала мысль, что там местами можно упростить

(0016086) zed (manager) 30-06-2015 09:20	>База сама или в UTF-8 или в UTF-16. Что напишешь - то и будет. Это понятно, не понятно как поведёт себя CompareStringW при сравнении строк, скажем, на немецком языке, если у меня в системе он не установлен. Я подозреваю, что она обломается. >базу сразу в UTF-16 создать? Это мне совсем не нравится. По крайней мере, пока у нас используется D2007 как основной компилятор. Пример на хабре видел, но там только для русского языка сделано.

(0016087) vasketsov (manager) 30-06-2015 09:46	>на немецком языке, если у меня в системе он не установлен Конечно, обломается. Локали если нет, то набор символов неизвестен и их порядок при сортировке и надо ли игнорировать дефисы и приводить умляуты - тоже. Я так на оракле последний раз тренировался. Накидал записей в таблицу на русском, английском, китайском и немецком. Так вот по отсутствующим локалям LIKE работает (если запрос вида like '%X%', где X - специфический для языка символ) так, как будто все эти символы одинаковые (все неизвестные - эквивалентны). >пока у нас используется D2007 как основной компилятор А где связь? Когда будет юникодный компилятор, если предположить, что отрелизишься до этого, как раз будет поздно пить боржоми. На существующих базах нельзя поменять UTF-8 на UTF-16. Только экспортом-импортом всей базы. Придётся оба варианта поддерживать, а так только UTF-16. А оба варианта поддерживать - тот ещё хардкор. Например, сейчас во все функции LogicalCollactionCompare у меня на базе UTF-8 прилетает всегда UTF-8, хотя вызываются они все в разных ситуациях (специально проверял, отдавая разный тип у текста в запрос). Соответственно, в случае поддержки обоих вариантов, придётся проверять, что же такое прилетело, внутри самой функции, или заранее смотреть, в каком формате база, ну и attach-у надо будет сказать досвидания. Мне китайцы всякие интересны в SQLite не сильно, потому что я уже тогда знал, что буду делать юникодные метки в СУБД. Но в твоём случае как раз может быть лучше сразу сделать базу UTF-16. Это скорее всего на обычной работе вообще не скажется, если там всё ходит по индексу, разве что время полнотекстового поиска вырастет да размер базы за счёт размера строк.

Users who viewed this issue
User List	Anonymous (2912x), stepanxxx (33x), zed (14x), vdemidov (9x), Garl (2x), vasketsov (22x), bk99 (3x)
Total Views	2995
Last View	19-04-2024 08:31

Issue History
Date Modified	Username	Field	Change
25-06-2015 09:45	stepanxxx	New Issue
25-06-2015 09:52	vasketsov	Note Added: 0016076
25-06-2015 11:07	stepanxxx	Note Added: 0016077
25-06-2015 17:55	vasketsov	Note Added: 0016078
25-06-2015 18:01	vasketsov	Note Edited: 0016078	View Revisions
26-06-2015 10:09	stepanxxx	Note Added: 0016079
26-06-2015 11:26	vasketsov	Note Added: 0016080
26-06-2015 18:17	zed	Note Added: 0016081
29-06-2015 21:22	vasketsov	Note Added: 0016083
30-06-2015 06:57	zed	Note Added: 0016084
30-06-2015 08:56	vasketsov	Note Added: 0016085
30-06-2015 09:20	zed	Note Added: 0016086
30-06-2015 09:46	vasketsov	Note Added: 0016087
03-08-2015 08:18	vdemidov	Priority	high => low
03-08-2015 08:18	vdemidov	Severity	tweak => minor
03-08-2015 08:18	vdemidov	Status	new => confirmed
03-08-2015 08:18	vdemidov	Product Version	=> 141212
03-08-2015 08:18	vdemidov	Target Version	=> 40xxxx

Relationships

SASGIS