Actualmente estoy ejecutando un par de cliente/servidor Solr que funciona bien.La forma correcta de agregar un parámetro de consulta personalizado en Solr
Sin embargo, en algunos casos, la consulta de filtro (parámetro fq
) que se envía a Solr es bastante grande (puede tener miles de caracteres) y no se puede recortar. Como el análisis de consultas lleva only a fraction of the overall time, quiero experimentar con comprimir esta parte de consulta y enviarla a Solr.
Estaba pensando en modificar el cliente por lo que en lugar de fq
utiliza otro parámetro (por ejemplo, zfq
). Solr puede decidir: si recibe zfq
, lo usa y decodifica los datos en fq
. De lo contrario, debería comportarse como de costumbre.
¿Cuál es la forma estándar de lograr lo anterior? Parece que hay SearchHandler
, requestHandler
, <queryParser
(ambos en solrconfig.xml) y muchos otros y no estoy muy seguro de qué es lo menos intrusivo. Estoy bastante seguro con Lucene/Tomcat pero no sé mucho sobre las estructuras de datos de Solr.
Miles de caracteres en un solo 'fq' no parecen correctos. En lugar de tratar de evitar las limitaciones, pregúntese a usted mismo por qué * está superando esas limitaciones. Describe tu problema * real *. –
El verdadero problema está fuera del alcance de esta pregunta. Pero si quieres escucharlo, claro, ¡no hay problema! La longitud proviene de cómo se implementan los permisos. Para los clientes que tienen conjuntos de permisos amplios, la consulta de filtro se ve así: "*: * -category: 1 AND -category: 2 AND ... -category: N". Que es un candidato perfecto para la compresión a medida que el patrón se repite. – mindas
¿ha visto este problema JIRA sobre la seguridad a nivel de documento? https://issues.apache.org/jira/browse/SOLR-1834 –