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 Jitka <ji...@gmail.com> on 2014/05/27 23:55:17 UTC
search component needs access to results of previous component
Hello and thanks for reading my question.
If our high-level search handler doesn't get enough results back from a Solr
query, it tweaks the query, re-sends to Solr, and combines the result sets
from the two queries. I would like to modify our Solr set-up so that Solr
itself could handle the deciding, tweaking, re-sending and combining within
a single call.
My current thought is to create a FollowUpQueryComponent that would live in
the "last-components" section of the definition of our usual requestHandler
in solrconfig.xml.
The new component would take a look at the results of the default
QueryComponent and decide whether or not to tweak the query and bring about
another search. I tried to do the looking-and-tweaking at the aggregator
level in the new component's prepare() function, but ran into two problems.
1) The new component's prepare() function is called before the default
QueryComponent has done its work, so it doesn't have the information it
needs to decide whether the new call will be needed or not, and
2) Even if I postpone the decision until after the default QueryComponent's
results are in, as far as I can tell those results stay on the shards and
are not available to the aggregator.
Either I am going about this all wrong, or these must be standard problems
for creators of custom QueryComponents. Are there standard solutions? Any
feedback would be much appreciated.
Thanks,
Jitka
--
View this message in context: http://lucene.472066.n3.nabble.com/search-component-needs-access-to-results-of-previous-component-tp4138335.html
Sent from the Solr - User mailing list archive at Nabble.com.
Re: search component needs access to results of previous component
Posted by Jitka <ji...@gmail.com>.
Good question, Mikhail. I started by putting that logic in the prepare()
function by sheer force of habit, but have since moved it first to
distributedProcess() (my system is sharded) and now to handleResponses() (as
in MoreLikeThisComponent.java, which I am mimicking without understanding).
As of last night, the new query is being generated but I am not yet getting
back responses for it. I have created a new ShardRequest.PURPOSE_XXX value
for myself but don't know whether that was a good idea.
--
View this message in context: http://lucene.472066.n3.nabble.com/search-component-needs-access-to-results-of-previous-component-tp4138335p4139593.html
Sent from the Solr - User mailing list archive at Nabble.com.
Re: search component needs access to results of previous component
Posted by Mikhail Khludnev <mk...@griddynamics.com>.
Hello Jitka,
I wonder why you put the custom component logic into prepare() but not in
process()?
28.05.2014 1:55 пользователь "Jitka" <ji...@gmail.com> написал:
> Hello and thanks for reading my question.
>
> If our high-level search handler doesn't get enough results back from a
> Solr
> query, it tweaks the query, re-sends to Solr, and combines the result sets
> from the two queries. I would like to modify our Solr set-up so that Solr
> itself could handle the deciding, tweaking, re-sending and combining within
> a single call.
>
> My current thought is to create a FollowUpQueryComponent that would live in
> the "last-components" section of the definition of our usual requestHandler
> in solrconfig.xml.
> The new component would take a look at the results of the default
> QueryComponent and decide whether or not to tweak the query and bring about
> another search. I tried to do the looking-and-tweaking at the aggregator
> level in the new component's prepare() function, but ran into two problems.
>
> 1) The new component's prepare() function is called before the default
> QueryComponent has done its work, so it doesn't have the information it
> needs to decide whether the new call will be needed or not, and
>
> 2) Even if I postpone the decision until after the default QueryComponent's
> results are in, as far as I can tell those results stay on the shards and
> are not available to the aggregator.
>
> Either I am going about this all wrong, or these must be standard problems
> for creators of custom QueryComponents. Are there standard solutions? Any
> feedback would be much appreciated.
>
> Thanks,
> Jitka
>
>
>
>
> --
> View this message in context:
> http://lucene.472066.n3.nabble.com/search-component-needs-access-to-results-of-previous-component-tp4138335.html
> Sent from the Solr - User mailing list archive at Nabble.com.
>
Re: search component needs access to results of previous component
Posted by Jitka <ji...@gmail.com>.
Thanks for your reply. I'll check out that link.
--
View this message in context: http://lucene.472066.n3.nabble.com/search-component-needs-access-to-results-of-previous-component-tp4138335p4139409.html
Sent from the Solr - User mailing list archive at Nabble.com.
Re: search component needs access to results of previous component
Posted by Jack Krupansky <ja...@basetechnology.com>.
Better to implement this first at your application layer, and when you are
finally happy with the results then consider pushing it down into Solr, or
even better, leave it at the application level.
You might want to take a look at the "Unsupervised Feedback" feature of the
LucidWorks Search Solr-based product. It re-executes enhanced queries in a
query component. I don't think the source is available though. And I don't
recall if it was cloud-enabled.
See:
http://docs.lucidworks.com/display/lweug/Queries+and+Relevance
-- Jack Krupansky
-----Original Message-----
From: Jitka
Sent: Tuesday, May 27, 2014 5:55 PM
To: solr-user@lucene.apache.org
Subject: search component needs access to results of previous component
Hello and thanks for reading my question.
If our high-level search handler doesn't get enough results back from a Solr
query, it tweaks the query, re-sends to Solr, and combines the result sets
from the two queries. I would like to modify our Solr set-up so that Solr
itself could handle the deciding, tweaking, re-sending and combining within
a single call.
My current thought is to create a FollowUpQueryComponent that would live in
the "last-components" section of the definition of our usual requestHandler
in solrconfig.xml.
The new component would take a look at the results of the default
QueryComponent and decide whether or not to tweak the query and bring about
another search. I tried to do the looking-and-tweaking at the aggregator
level in the new component's prepare() function, but ran into two problems.
1) The new component's prepare() function is called before the default
QueryComponent has done its work, so it doesn't have the information it
needs to decide whether the new call will be needed or not, and
2) Even if I postpone the decision until after the default QueryComponent's
results are in, as far as I can tell those results stay on the shards and
are not available to the aggregator.
Either I am going about this all wrong, or these must be standard problems
for creators of custom QueryComponents. Are there standard solutions? Any
feedback would be much appreciated.
Thanks,
Jitka
--
View this message in context:
http://lucene.472066.n3.nabble.com/search-component-needs-access-to-results-of-previous-component-tp4138335.html
Sent from the Solr - User mailing list archive at Nabble.com.