Добрый день, коллеги. Вопрос по best practice со средствами поиска. Может кто

подскажет хорошее решение проблемы?

Допустим есть средство поиска с галкой "Полнотекстовый поиск по всем столбцам" и самодельным ФМ-ом выбора.
Для ветки, где searchkey пустой (по F4 который) всё просто и понятно, делаешь запрос с пришедшими фильтрами.
Проблема с поиском для выпадающего списка. Не нашёл надёжного, но простого способа реализации.

Знаю несколько вариантов решения, но все чем-то не нравятся.

1. Просто собираем фильтр field1 like '*<searchkey>*' OR field2 like '*<searchkey>*' .
Запрос падает в дамп если длина '*<searchkey>*' больше, чем длина какого-то из полей.

2. Собираем типизированные range нужной длины через OR
Некорректно работает когда длина '<searchkey>' равна или почти равна длине поля. Поле обрезается и фильтр получается кривой.
Например, фильтровали по БЕ(4 символа) = 1020. Фильтр обрезался до '*102'. В результате вместо нужных БЕ выводятся совсем другие.

3. Собирать строку where и учитывать длину поля. Что если '*<searchkey>*' не влезает в длину поля, то фильтр собирается иначе:
для searchkey 10 - bukrs like '*10*',
для searchkey 1020 - bukrs = '1020',
для searchkey 102 - ( bukrs like '*102' or bukrs like '102*', )
для searchkey 10201 - совсем не используем это поле

Думаю это хорошее направление. Но боюсь логика получится слишком муная, и что-то да не учтёшь. Например для

4. Тупо читают все данные (или почти все), а потом фильтруют на инстанции.
В большинстве случаев будет работать медленно.

5. Делают CDS с заведомо длинными полями (или даже одним) и фильтруют по ним.
Технически вроде бы и работает. Но явный костыль, и на код-ревью докапываются, потому что есть ворнинги.

6. Делают AMDP, чтобы фильтр формировался внутри HANA. Тогда запрос отрабатывает нормально, не падает.
Технически работает (вроде бы). Но на мой вкус это как-то дофига возьни из-за такой мелкой задачи.

почему не собирать рейндж на базе строки? тогда п2 и п3 будут в одно лицо и будут отрабатывать

П2 будет работать некорректно в некоторых случаях. Там написан один из примеров из же. П3 - попытка решить эту проблему накручиванием доп логики по длине фильтра. на вскидку должно сработать. Но может есть способ проще.

не, я ж говорю: если рейндж из строки, то обрезки быть не должно и п2 будет работать. в ТМ на этом построена кое-какая стандартная техника получения данных из динамических запросов

Если не учитывать длину поля, чтобы не обрезался фильтр, то запрос падает. Это п.1.

неа. не падает. стандарт юзает рейнж из строки и все корректно работает

Ну логично, что они это в какой-то версии поправили. Но к сожалению в той системе, что я сейчас работаю, падает.

я бы еще раз проверил в ваше версии, т.к. оно и в старых нормально работало

Пошёл по пути 3. Вроде не такая уж и сложная логика получается.

возможно я неверно понимаю задачу, но я бы решал так: 1) Делаешь CDS со столбцом конкатинацией нужных, цепляешь ракурс в средство поиска, ставишь там галочки для поиска TREX(точное название не помню) 2) делать амдп с fuzzy для нужных столбцов. Если делать через LIKE, то по вводу с опечатками не будет результатов, а обычно их хотят.

1. В моём случае не только ракурс, но и ФМ требовался. поэтому просто галочками не решить. То есть фильтрацию приходится организовывать кодом. Вариант с конкатенацией полей и поиском по нему рассматривал (и даже пробовал). Но во-первых костыль, во-вторых есть опасение, что код-ревью у заказчика не пройдёт из-за ворнингов в cds. 2. AMDP мне пока не нравится - имхо перебор для такой мелкой задачи. fuzzy в данном случае вроде не требуют. Там куча средства поиска на ФМ-ах. И почти все имеют какие-то из перечисленных проблем. Фуззи нигде не видел. На мой личный вкус я выкрутился, что называется, достаточно хорошо.