2012-04-04 7 views
6

Estamos utilizando Solr 3.5 con el esquema que tiene la siguiente declaración de campo:Solr consulta: dejar de palabras, O e Y rareza

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

Cuando enviamos una consulta como esta:

field1:"term1" 

Solr devuelve resultados

Cuando ejecuta esta consulta todavía nos llegan los resultados:

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

Mientras que término2 es una palabra vacía y término1 es una palabra regular.

Pero cuando enviamos una consulta como esta:

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

Nada vuelve.

También hay que destacar que cuando hacemos algo como:

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

también funciona, pero a medida que la consulta real debería buscar un término en unos 200 campos, esta opción es menos preferido.

Gracias.

+1

¿Y cuál es su resultado esperado? Dado que term2 es una palabra de parada, ¿no debería esperar que no haya resultados para las consultas segunda y tercera? De todos modos, el primer paso que debe tomar es inspeccionar su índice con Luke, solo para estar seguro de qué es exactamente lo que está cuestionando. –

+0

Estaba esperando que la palabra parada no afectara los resultados, la consulta como _term1_ _term2_ debería devolver todos los documentos que coinciden con _term1_ cuando _term2_ es una palabra de finalización. Voy a intentar las pruebas, gracias. – Noam

+1

Sí, el análisis de una palabra de advertencia no produce tokens, por lo que todo el término de la consulta debe aparecer como si no estuviera allí. Pero creo que esto presenta un desafío para QueryParser. Su segunda consulta es una BooleanQuery de dos cláusulas donde la cláusula correcta es una BooleanQuery interna. Esta consulta interna resulta no tener cláusulas si term2 es una palabra de parada, por lo que a Lucene le queda una BooleanQuery vacía. Me pregunto cómo maneja eso. Hubo (hace mucho tiempo, pero todavía) un [problema] JIRA (https://issues.apache.org/jira/browse/LUCENE-933) sobre exactamente este caso. –

Respuesta

1

Supongo que su 'wierdness' tiene más que ver con sus reglas de solrconfig en lugar de su consulta con stopwords. He experimentado problemas similares con las consultas de stopword dentro de las subconsultas y terminaron siendo mis reglas de coincidencia mínima en mi controlador de búsqueda Dismax.

Busque dentro de su solrconfig.xml y busque el requestHandler que su búsqueda está utilizando. Debería tener una cadena "mm" (Partida mínima) declarada. Intenta ajustar tus reglas para que sean menos o más restrictivas, sea cual sea tu objetivo.

¡La mejor de las suertes!