lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <j...@apache.org>
Subject [jira] Commented: (SOLR-2026) Need infrastructure support in Solr for requests that perform multiple sequential queries
Date Thu, 26 Aug 2010 22:24:54 GMT

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

Hoss Man commented on SOLR-2026:
--------------------------------

bq. I understand those use-cases but I still have a hard time to understand why this would
require something like a scripting engine.

Maybe we have an XY Problem here?

I read the description of this issue, and see that the goal is for a single request fro ma
client, to result in Solr internally executing multiple sequential requests, where the result
of request N can be used to influence requests N+M.

My thought process based on that reading, is that in order to be useful, some mechanism is
needed when configuring these sequential requests, so that the perosn writting the config
can say "extract some value X from the result of request N using the following rule, use value
X as input for request M using the following rule" -- and that sounds like scripting to me.

If the infrastructure for executing these sequential requests doesn't support a mechanism
like this natively, then it seems like it would only be useful for triggering sequential requests
to special case RequestHandlers that know they will be used in this manner, and have special
code for getting the variables they expect from the output of the RequestHandlers that come
before then in the sequence -- but in that case, the infrastructure doesn't really do anything
for you, these custom Requesthandlers could do the sequential execution themselves (that part
is really trivial)

I can imagine *lots* of use cases where this functionality would be useful with existing (general
purpose) request handlers provided it allowed scripting in it's config to control how the
output of one affected the input of another (ie: two hits to the same SearchHandler, the second
one replcaeing hte "q" param with the top term returned by the SpellCheckComponent from the
first request) but i haven't been able to think of a use case where it would be useful w/o
this type of configuration.

Can you provides some details on the type of use case you are thinking of that wouldn't require
some type of scripting?

So far the only example posted is Karl's, where as he described it the request handler in
the second request would absolutely have to be some custom plugin that knows to look at SolrRequestObject.getContext().get("previousresponse")

> 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: New Feature
>          Components: SearchComponents - other
>            Reporter: Karl Wright
>            Assignee: Simon Willnauer
>            Priority: Minor
>             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