Блог

Главная - Вопросы по программированию - Запрос Solr с пробелами и с запросом и операцией

Запрос Solr с пробелами и с запросом и операцией

#solr

Вопрос:

Я работаю над решением для поиска в своем проекте, и все работает нормально, за исключением одного сценария. Операция поискового запроса-это И (q.op=И), когда я ищу что-то, например: 40486 52P.57 это не дает никаких результатов (здесь запрос готовится на java), но когда я выполняю тот же поиск в панели администратора solr, он дает правильные результаты. В моем коде Java я избегаю поискового запроса , поэтому запрос передается в solr, как q : 40486\ 52P.57 , но когда я выполняю его в администраторе solr, это было похоже q : 40486 52P.57 .

Примечание: два слова в приведенном выше поисковом запросе относятся к двум разным полям.

Другая вещь, которую я заметил, было то, что если слова в поисковом запросе относятся к одной сфере, то результаты идут прекрасно без каких-либо проблем, например: 40486 67 когда оба слова принадлежат к одной области, а запрос из моего кода Java был q: 40486\ 67 и в гумз админ был q : 40486 67 , но в обоих случаях он работает нормально.

Я не видел здесь никаких проблем, может кто-нибудь, пожалуйста, помочь мне в этом?

Обновить

Я нашел основную причину, по которой это не работает. Проблема в том, что при выходе из пространства. На самом деле я использую отдельные поля qf для поиска 100% совпадения, я имею в виду mm=100 в данном случае. Таким образом, выход из пространства приведет к тому, что запрос будет выглядеть как q : 40486\ 52P.57 и не даст результатов, но если я использую многополевое поле со всеми полями, доступными для поиска, то это даст результаты, даже если запрос есть q : 40486\ 52P.57 . Является ли это ограничением для edismax в solr? может кто-нибудь, пожалуйста, помочь мне, как это исправить, не создавая мультиполя? Я ожидаю, что он должен работать даже после выхода из пространства, используя отдельные поля в qf параметре.

Примерный индекс:

 {
productNumber : 40486754,
productShot : 52P.57 UTM, 
description : something,
general_search {
  40486754,
  52P.57 UTM,
  something
}
},
{
productNumber : 12345,
productShot : 52P.57 ABC, 
description : xzy,
general_search {
  12345,
  52P.57 ABC,
  xzy
}
}

Примеры запросов:
Запрос 1:

qt=/selectamp;q.op=ANDamp;defType=edismaxamp;q=40486 52P.57amp;qf=productNumber productShot description

Запрос 2:

qt=/selectamp;q.op=ANDamp;defType=edismaxamp;q=40486 52P.57amp;qf=productNumber productShot description

Запрос 3:

qt=/selectamp;q.op=ANDamp;defType=edismaxamp;q=40486 52P.57amp;qf=general_search

в приведенных выше запросах запросы 2 и 3 работают, но не запрос 1

Комментарии:

1. Я бы предложил добавить debug=true к вашим запросам и в ответе посмотреть на debug/parsedQuery значение и посмотреть, сможете ли вы определить, что между ними анализируется по-разному.

2. Привет @HectorCorrea, извините за поздний ответ. Да, я сделал это, и проблема заключалась в том, что пробел был удален, когда я не избежал пробелов, это работает так, как ожидалось. На самом деле, когда пробел был удален, поиск был похож на «40486 52 Стр. 57» и рассматривался как одно слово, а когда пробел не был удален, это было похоже на два разных слова 40486 и 52 стр. 57, так что это работает.

Ответ №1:

Проблема заключалась в том, чтобы избежать пробелов. Когда я избегал пробела, оно рассматривалось как одно слово «40486 52P.57», а когда пробел не был удален, оно рассматривалось как два разных слова 40486 и 52P.57, так что все работает нормально.

Метки: