lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject RE: What is the best way in Solr to perform iterative search?
Date Tue, 03 Aug 2010 17:16:04 GMT
Thanks - I've got the latter situation, actually.

I presume when you wrote your QueryComponent you did the query first execution, modification,
and second execution all within the equivalent of the prepare() method?  I didn't want to
replace QueryComponent itself, since it does a fair bit of stuff, but maybe I can extend it
and just override the appropriate method...


-----Original Message-----
From: ext Erik Hatcher [] 
Sent: Tuesday, August 03, 2010 1:01 PM
Subject: Re: What is the best way in Solr to perform iterative search?

I'm not quite clear on what you want ... if you want to "search within  
previous search results", simply take the original query and turn it  
into an fq parameter for the next request using the new query as the q  

If you want to take some part of the current results to form a new  
query internally to Solr, it sounds like what you want is a custom  
QueryComponent.  I've done this, for example, to back off a search  
that had zero results and broaden it automatically.  Register a new  
QueryComponent as "query" and it'll replace the existing one - in  


On Aug 3, 2010, at 12:18 PM, <> < 
 > wrote:

> Folks,
> I have a search task which needs to do the following:
> 	* Do a search
> 	* Use the results of that search to form a final query, which when  
> executed returns the overall results
> The question is, what is the best way to build components within  
> Solr to handle this request flow?  My first thought was to construct  
> two QParserPlugin objects, one for each query, and then perhaps  
> write a custom version of QueryComponent that does the job.   But I  
> certainly can't put all the above logic into one SearchComponent,  
> because of the requirement that I need the results from one search  
> to do the subsequent one.  I *could* replace or extend the  
> requestHandler instead.  Or, I could have multiple SearchComponent's  
> in the pipeline where one looks at the other's results (will this  
> work???)  Any other ideas?
> Karl

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message