[
https://issues.apache.org/jira/browse/SOLR-5005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13701791#comment-13701791
]
David Smiley commented on SOLR-5005:
------------------------------------
It's great to see you take a first cut at this Karthick. I reviewed your patch.
I was expecting a single script that has essentially full control of the logic
of how to handle a request, and it would unlikely extend SearchHandler to do
this. If it wanted to loop N times and do that many internal searches where N
is possibly dependent on the parameters, it could. If it didn't want to do any
searches and simply return "Hello World" or add a couple parameters together,
it could. I wish I articulated this vision...
The approach you've taken here surprises me because it wasn't what I expected.
It is more limited in that it can only "wrap" essentially a SearchHandler
request by having the opportunity to intercept the parameters beforehand and
modify the response afterwards. And it is a fixed preconfigured stack of
searches; it can't do a dynamic number of searches. Is there some advantage to
your approach I'm missing?
If we agree on the script being in-charge of actually executing the search, I
think it should be easier to write simple scripts without the Java API
bulk/complexity if there was a helper class exposed to the binding that is used
to do the search. This might be the facade design pattern. The script
shouldn't have to reference LocalSolrQueryRequest and ModifiableSolrParams by
name, for example. It might take some time in actually using early iterations
of this patch before we know what this facade should look like to make the
script code light.
> ScriptRequestHandler
> --------------------
>
> Key: SOLR-5005
> URL: https://issues.apache.org/jira/browse/SOLR-5005
> Project: Solr
> Issue Type: New Feature
> Reporter: David Smiley
> Attachments: patch
>
>
> A user customizable script based request handler would be very useful. It's
> inspired from the ScriptUpdateRequestProcessor, but on the search end. A user
> could write a script that submits searches to Solr (in-VM) and can react to
> the results of one search before making another that is formulated
> dynamically. And it can assemble the response data, potentially reducing
> both the latency and data that would move over the wire if this feature
> didn't exist. It could also be used to easily add a user-specifiable search
> API at the Solr server with request parameters governed by what the user
> wants to advertise -- especially useful within enterprises. And, it could be
> used to enforce security requirements on allowable parameter valuables to
> Solr, so a javascript based Solr client could be allowed to talk to only a
> script based request handler which enforces the rules.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
