2012-04-04 17 views
6

Stiamo utilizzando Solr 3.5 con schema che ha la seguente dichiarazione di campo:Solr query: smettere di parole, OR e AND stranezza

<fieldType name="fieldN" class="solr.TextField" positionIncrementGap="100"> 
    <analyzer type="index"> 
    <tokenizer class="solr.WhitespaceTokenizerFactory"/> 
    <filter class="solr.WordDelimiterFilterFactory" 
      generateWordParts="0" generateNumberParts="0" catenateWords="0" catenateNumbers="0" 
      catenateAll="0" splitOnCaseChange="1" splitOnNumerics="0" preserveOriginal="1"/> 
    <filter class="solr.LengthFilterFactory" min="2" max="256"/> 
    <filter class="solr.LowerCaseFilterFactory"/> 
    <filter class="solr.StopFilterFactory" 
      ignoreCase="true" words="stopwords.txt" enablePositionIncrements="true" 
      /> 
    <filter class="solr.PorterStemFilterFactory"/> 
    </analyzer> 
    <analyzer type="query"> 
    <tokenizer class="solr.WhitespaceTokenizerFactory"/> 
    <filter class="solr.LengthFilterFactory" min="2" max="256"/> 
    <filter class="solr.LowerCaseFilterFactory"/> 
    <filter class="solr.StopFilterFactory" 
      ignoreCase="true" words="stopwords.txt" enablePositionIncrements="true" 
      /> 
    <filter class="solr.PorterStemFilterFactory"/> 
    </analyzer> 
</fieldType> 

Quando inviamo una query come questa:

field1:"term1" 

Solr restituisce risultati.

Quando si esegue questa query ancora otteniamo risultati:

field1:"term1" AND (field2:term2 OR field3:term2) 

Mentre term2 è una parola stop e term1 è una parola normale.

Ma quando inviamo una query come questa:

field1:"term1" AND (field2:term2 OR field3:term2 OR field4:term2) 

Nulla ritorna.

Abbiamo anche notato che quando facciamo qualcosa di simile:

(field1:"term1" AND (field2:term2 OR field3:term2)) OR (field1:"term1" AND field4:term2) 

lavora troppo, ma come la vera query deve cercare un termine in circa 200 campi, questa opzione è meno preferito.

Grazie.

+1

E qual è il risultato atteso? Poiché term2 è una parola d'arresto, non dovresti aspettarti risultati per la seconda e terza query? Ad ogni modo, il primo passo che dovresti fare è ispezionare il tuo indice con Luke, solo per essere sicuro di cosa stai cercando esattamente. –

+0

Mi aspettavo che la parte della parola di arresto non influisse sui risultati, query come _term1_ _term2_ dovrebbe restituire tutti i documenti che corrispondono a _term1_ quando _term2_ è una parola di arresto. Proverò i test, grazie. – Noam

+1

Sì, l'analisi di una stopword non genera token, quindi l'intero termine della query dovrebbe essere come se non ci fosse. Ma penso che questo rappresenti una sfida per QueryParser. La tua seconda query è una BooleanQuery di due clausole in cui la clausola di destra è una BooleanQuery interna. Questa query interna risulta priva di clausole se term2 è una parola d'ordine, quindi Lucene viene lasciato con una BooleanQuery vuota. Mi chiedo come lo gestisce. C'era (molto tempo fa, ma ancora) un JIRA [problema] (https://issues.apache.org/jira/browse/LUCENE-933) su esattamente questo caso. –

risposta

1

Immagino che la tua "stranezza" abbia più a che fare con le tue regole di solrconfig piuttosto che con la tua query con stopword. Ho riscontrato problemi simili con le query di stopword all'interno delle sottoquery e sono state le mie regole di corrispondenza minima nel mio gestore di ricerca Dismax.

Cerca all'interno del tuo solrconfig.xml e cerca la requestHandler utilizzata. Dovresti avere una stringa "mm" (Minimum Match) dichiarata. Prova ad adattare le regole in modo che siano meno o più restrittive, qualunque sia il tuo obiettivo.

Buona fortuna!