lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Smiley (JIRA)" <>
Subject [jira] [Commented] (SOLR-5005) ScriptRequestHandler
Date Mon, 08 Jul 2013 05:33:50 GMT


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:
>             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:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message