lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simon Willnauer (JIRA)" <j...@apache.org>
Subject [jira] Commented: (SOLR-2026) Need infrastructure support in Solr for requests that perform multiple sequential queries
Date Fri, 13 Aug 2010 11:42:17 GMT

    [ https://issues.apache.org/jira/browse/SOLR-2026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12898195#action_12898195
] 

Simon Willnauer commented on SOLR-2026:
---------------------------------------

bq. Wouldn't this be more straight forward as it's own distinct RequestHandler (that didn't
even know about SearchComponents?
It would be at least the cleaner solution and I like it. I am actually quiet happy that some
of the more "solr" experienced people (thanks hoss :) jumped in and looked at that. I still
don't  understand what this has to do with scripting engines but I guess it you folks have
you usecase as I do...

bq. There doesn't seem to be any reason why the logic even needs to be aware of when it's
used in a distributed fashion
Maybe I miss something but where am I aware of if I'm distributed? I don't see this - enlighten
me please! From the outside this looks like a single request which can for sure be done via
a "SequentialRequestHandler" which delegates down to a list of SearHandler instances. If the
request is distributed I actually might not want the coordinator to fire a distributed request
for each SearchHandler it has configured but maybe fire the distributed request on a higher
level eg. the SequentialRequestHandler instance on the distributed nodes it is talking to.
It would safe a whole set of network roundtrips, right? I guess both has valid use-cases so
this should probably be configurable...  

bq. SearchHandler could remain untouched, and keep it's current focus (managing SearchComponents)
while the new SequentialRequestHandler would focus on executing independdent sub queries in
sequence.

+1 yeah that makes lots of sense to me, plus bw compat comes for free - I will update the
patch

simon

> Need infrastructure support in Solr for requests that perform multiple sequential queries
> -----------------------------------------------------------------------------------------
>
>                 Key: SOLR-2026
>                 URL: https://issues.apache.org/jira/browse/SOLR-2026
>             Project: Solr
>          Issue Type: Improvement
>          Components: SearchComponents - other
>            Reporter: Karl Wright
>            Assignee: Simon Willnauer
>             Fix For: 4.0
>
>         Attachments: SOLR-2026.patch, SOLR-2026.patch
>
>
> Several known cases exist where multiple index searches need to be performed in order
to arrive at the final result.  Typically, these have the constraint that the results from
one search query are required in order to form a subsequent search query.  While it is possible
to write a custom QueryComponent or search handler to perform this task, an extension to the
SearchHandler base class would readily permit such query sequences to be configured using
solrconfig.xml.
> I will be therefore writing and attaching a patch tomorrow morning which supports this
extended functionality in a backwards-compatible manner.  The tricky part, which is figuring
out how to funnel the output of the previous search result into the next query, can be readily
achieved by use of the SolrRequestObject.getContext() functionality.  The stipulation will
therefore be that the SolrRequestObject's lifetime will be that of the entire request, which
makes complete sense.  (The SolrResponseObject's lifetime will, on the other hand, be limited
to a single query, and the last response so formed will be what gets actually returned by
SearchHandler.)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message