Solr Shingle ist nicht in Debug-Abfrage

Question

Ich versuche, Solr zu verwenden, um genaue Übereinstimmungen für Kategorien in einer Benutzersuche (e.g. "skinny jeans" in "blue skinny jeans") zu finden. Ich verwende die folgende Typdefinition:

<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> 

Der Typ Willen Indexkategorien ohne Tokenisieren, nur mit Unterstrichen Leerzeichen ersetzt. Aber es wird Abfragen Tokenize und schindel sie (mit Unterstrichen).

Was ich versuche zu tun ist, die Query Schindeln mit den indizierten Kategorien übereinstimmen. In der Seite Solr Analyse kann ich sehen, dass die Leerzeichen/unterstreichen Ersatz beiden Werke auf dem Index und Abfrage, und ich kann sehen, dass die Abfrage richtig geschuppt wird (Abbildung unten):

Mein Problem ist, dass in der Solr-Abfrage-Seite kann ich nicht sehen, dass Schindeln erzeugt werden, und ich nehme an, dass als Ergebnis die Kategorie "Skinny Jeans" nicht übereinstimmt, aber die Kategorie "Jeans" ist abgestimmt :(

Dies ist die Debug-Ausgabe:

{ 
    "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" 
    } 
} 

Es ist klar, dass der Parameter parsedquery die schindelförmige Abfrage nicht anzeigt. Was muss ich tun, um den Abgleich von Query-Schindeln mit indizierten Werten abzuschließen? Ich habe das Gefühl, dass ich diesem Problem sehr nahe bin. Jeder Rat wird geschätzt!

Answer 1

Dies ist eine unvollständige Antwort, aber es könnte ausreichen, um Sie in Bewegung zu bringen.

1: Sie wollen wahrscheinlich outputUnigrams="false", so dass Sie nicht der Kategorie „Jeans“ auf Abfrage „Skinny Jeans“

2 entsprechen: Sie wollen eigentlich nicht mit Anführungszeichen suchen, (ein Satz) oder das Feld gewonnen Ich werde nie mehr als ein Token sehen.

3: Es scheint, wie Sie versuchen, die gleiche Sache zu tun, wie diese Person war: http://comments.gmane.org/gmane.comp.jakarta.lucene.user/34746

Das Gewinde, wie es auf die Aufnahme des PositionFilterFactory https://wiki.apache.org/solr/AnalyzersTokenizersTokenFilters#solr.PositionFilterFactory

Wenn Sie führen aussieht‘ Verwenden Sie Solr < 5.0, versuchen Sie das am Ende Ihrer Abfrage Zeitanalyse und sehen, ob es funktioniert.

Leider wurde diese Filterfabrik in 5.0 entfernt. Dies ist der einzige Kommentar, den ich gefunden habe, was stattdessen zu tun: http://lucene.apache.org/core/4_10_0/analyzers-common/org/apache/lucene/analysis/position/PositionFilter.html

ich mit autoGeneratePhraseQueries ein wenig gespielt, aber ich habe noch einen anderen Weg finden Solr zu verhindern, dass ein MultiPhraseQuery zu erzeugen.