[
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: [email protected]
For additional commands, e-mail: [email protected]
