You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Steve Pruitt <bp...@opentext.com> on 2017/07/31 21:07:37 UTC
programmatically setting filter query not working for me
My use case is programmatically setting a query filter before executing the query. I have a search component in the /select first-components list.
This component determines the filter query value and sets it in the process method. I pass in a custom param to trigger the filter creation
I grab the parms from the request
SolrParams solrParams = rb.req.getParams();
I next create a collection called rawParams with
Map<String, String[]> rawParams = SolrParams.toMultiMap(solrParams.toNamedList());
I create the structure to hold my filters and
String[] filters = getFilter...
and then assign the new params like this
rawParams.put(CommonParams.FQ, filters);
solrParams = new MultiMapSolrParams(rawParams);
rb.req.setParams(solrParams);
The filter returns only a subset of the documents matching the terms. In my test case its 2 out of 21 documents.
The problem is the response is all 21 documents.
I have a simple search component in the last-components list simply to set a breakpoint to see the query results.
I have tried two alternate tests using the Solr Admin console.
I first verified the filter query by directly pasting it in the fq field and it works ok. I got back the expected 2 documents.
I next did the above and also included my custom params. And this worked. As expected, the SolarParms value of the req has a double entry for the filter. The values are identical.
So without using the fq field in the Console, I can't determine why setting via the Solr parms with Commons.FQ key doesn't work.
As a separate experiment, created a custom handler and with a custom component sub classing QueryComponent. I do the filter query setup as above and calling super.process(rb) works.
But, I don't want to use a custom handler.
Thanks in advance if anyone points out where my assumptions are wrong.
Thanks,
Steve