[
https://issues.apache.org/jira/browse/SOLR-1725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13278257#comment-13278257
]
Andrzej Bialecki commented on SOLR-1725:
-----------------------------------------
Erik, good stuff, very much needed!
My comments relate to a use case that would require extending this
functionality to be able to re-configure the processor on the fly (without a
core reload) and to support non-file based scripts (e.g. parsing scripts from
SolrParams). Currently these classes are not extensible at all, but only small
modifications would be required to make them much more powerful and reusable:
* I'd like to be able to re-configure SUPFactory programatically and not via
init args. The implementation appears to handle this by not throwing an
exception if <script></script> exists and is empty. That's fine, but if it
wasn't intentional then please don't block it ;)
* could you please change initEngines(req,rsp) and associated private classes
(and members in SUPFactory) to protected? I'd like to be able to customize
these parts, too.
* actually, I don't like ScriptFile at all, and it's baked into EngineInfo so
that I can't get rid of it - in my use case I wouldn't have a file, and anyway
the whole idea of re-reading actual files on each request is doubtful, in terms
of performance... I'd rather see something like this:
{code}
protected static class Script {
private final String scriptName;
private final String type;
private final byte[] script;
protected Script(String scriptName, String type, byte[] content) {
...
}
...
}
{code}
I.e. to separate the actual content of the script from the way we obtain it,
and do the reading as a part of init(args), so that it's customizable. The
benefit of this is also that we would cache the script content so that no IO
would be needed on each request. Then initEngines(..) could simply open a
reader on the cached bytes to eval() the script.
> Script based UpdateRequestProcessorFactory
> ------------------------------------------
>
> Key: SOLR-1725
> URL: https://issues.apache.org/jira/browse/SOLR-1725
> Project: Solr
> Issue Type: New Feature
> Components: update
> Affects Versions: 1.4
> Reporter: Uri Boness
> Assignee: Erik Hatcher
> Labels: UpdateProcessor
> Fix For: 4.1
>
> Attachments: SOLR-1725-rev1.patch, SOLR-1725.patch, SOLR-1725.patch,
> SOLR-1725.patch, SOLR-1725.patch, SOLR-1725.patch, SOLR-1725.patch
>
>
> A script based UpdateRequestProcessorFactory (Uses JDK6 script engine
> support). The main goal of this plugin is to be able to configure/write
> update processors without the need to write and package Java code.
> The update request processor factory enables writing update processors in
> scripts located in {{solr.solr.home}} directory. The functory accepts one
> (mandatory) configuration parameter named {{scripts}} which accepts a
> comma-separated list of file names. It will look for these files under the
> {{conf}} directory in solr home. When multiple scripts are defined, their
> execution order is defined by the lexicographical order of the script file
> name (so {{scriptA.js}} will be executed before {{scriptB.js}}).
> The script language is resolved based on the script file extension (that is,
> a *.js files will be treated as a JavaScript script), therefore an extension
> is mandatory.
> Each script file is expected to have one or more methods with the same
> signature as the methods in the {{UpdateRequestProcessor}} interface. It is
> *not* required to define all methods, only those hat are required by the
> processing logic.
> The following variables are define as global variables for each script:
> * {{req}} - The SolrQueryRequest
> * {{rsp}}- The SolrQueryResponse
> * {{logger}} - A logger that can be used for logging purposes in the script
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
