2016-05-25 8 views
3

Я пытаюсь использовать Solr для поиска точных совпадений по категориям в поиске пользователей (e.g. "skinny jeans" in "blue skinny jeans"). Я использую следующее определение типа:Solr Shingle не отображается в отладочном запросе

<fieldType name="subphrase" class="solr.TextField" positionIncrementGap="100" autoGeneratePhraseQueries="true"> 
    <analyzer type="index"> 
    <charFilter class="solr.PatternReplaceCharFilterFactory" 
       pattern="\ " 
       replacement="_"/> 
    <tokenizer class="solr.KeywordTokenizerFactory"/> 
    </analyzer> 
    <analyzer type="query"> 
    <tokenizer class="solr.WhitespaceTokenizerFactory"/> 
    <filter class="solr.ShingleFilterFactory" 
      outputUnigrams="true" 
      outputUnigramsIfNoShingles="true" 
      tokenSeparator="_" 
      minShingleSize="2" 
      maxShingleSize="99"/> 
    </analyzer> 
</fieldType> 

типа категории индексных без tokenizing, только заменяя пробелы с подчеркиванием. Но он будет tokenize запросов и shingle их (с подчеркиванием).

То, что я пытаюсь сделать, соответствует запросу черепицы по индексированным категориям. На странице анализа Solr я могу видеть, что пробельные/подчеркивание замены работает как индекс и запрос, и я могу видеть, что запрос быть дранкой правильно (скриншот ниже):

Successful whitespace modification on index, and shingle generation on query

Моя проблема заключается в том, что на странице Solr Query я не вижу, как генерируется черепица, и я полагаю, что в результате категория «тощие джинсы» не соответствует, но категория «джинсы» сопоставляется :(

Это отладочный вывод:

{ 
    "responseHeader": { 
    "status": 0, 
    "QTime": 1, 
    "params": { 
     "q": "name:(skinny jeans)", 
     "indent": "true", 
     "wt": "json", 
     "debugQuery": "true", 
     "_": "1464170217438" 
    } 
    }, 
    "response": { 
    "numFound": 1, 
    "start": 0, 
    "docs": [ 
     { 
     "id": 33, 
     "name": "jeans", 
     } 
    ] 
    }, 
    "debug": { 
    "rawquerystring": "name:(skinny jeans)", 
    "querystring": "name:(skinny jeans)", 
    "parsedquery": "name:skinny name:jeans", 
    "parsedquery_toString": "name:skinny name:jeans", 
    "explain": { 
     "33": "\n2.2143755 = product of:\n 4.428751 = sum of:\n 4.428751 = weight(name:jeans in 54) [DefaultSimilarity], result of:\n  4.428751 = score(doc=54,freq=1.0), product of:\n  0.6709952 = queryWeight, product of:\n   6.600272 = idf(docFreq=1, maxDocs=541)\n   0.10166174 = queryNorm\n  6.600272 = fieldWeight in 54, product of:\n   1.0 = tf(freq=1.0), with freq of:\n   1.0 = termFreq=1.0\n   6.600272 = idf(docFreq=1, maxDocs=541)\n   1.0 = fieldNorm(doc=54)\n 0.5 = coord(1/2)\n" 
    }, 
    "QParser": "LuceneQParser" 
    } 
} 

Понятно, что параметр parsedquery не отображает черепичный запрос. Что мне нужно сделать, чтобы завершить процесс сопоставления черепицы запроса с индексированными значениями? Я чувствую, что я очень близок к этой проблеме. Любые советы приветствуются!

+0

Вы пробовали название: «тощие джинсы»? – MatsLindh

+0

Да, ничего не возвращается, даже «джинсы». Это может быть связано с другим вопросом, который я поднял @ [link] (https://stackoverflow.com/questions/37425263/solr-keywordtokenizerfactory-exact-match-for-multiple-words-not-working) As @ Abhijit Bashetti упомянул, что токены не работают таким образом, они не подвержены последствиям. Кроме того, я действительно не хочу, чтобы он работал таким образом, я не хочу использовать кавычки, поскольку я ищу подстроку, и это победит цель. – mils

ответ

2

Это неполный ответ, но этого может быть достаточно, чтобы заставить вас двигаться.

1: Вы, вероятно, хотите outputUnigrams="false", так что вы не соответствуют категории «джинсы» на запрос «узкие джинсы»

2: Вы на самом деле хотите, чтобы искать в кавычки (фразу) или поля вон Никогда не видел больше одного знака для гальки.

3: Похоже, что вы пытаетесь сделать то же самое, что этот человек был: http://comments.gmane.org/gmane.comp.jakarta.lucene.user/34746

Этот поток выглядит как это приведет к включению PositionFilterFactory https://wiki.apache.org/solr/AnalyzersTokenizersTokenFilters#solr.PositionFilterFactory

Если вы» повторно используя Solr < 5.0, попробуйте поместить это в конце анализа времени запроса и посмотреть, работает ли он.

К сожалению, этот завод фильтра был удален в 5.0. Это единственный комментарий, который я нашел, что делать вместо этого: http://lucene.apache.org/core/4_10_0/analyzers-common/org/apache/lucene/analysis/position/PositionFilter.html

Я играл с autoGeneratePhraseQueries немного, но я до сих пор найти другой способ предотвратить Solr от генерации MultiPhraseQuery.

+0

Есть некоторые моменты :) – mils

 Смежные вопросы

  • Нет связанных вопросов^_^