[
https://issues.apache.org/jira/browse/SOLR-1725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-1725:
---------------------------
Attachment: SOLR-1725.patch
bq. Are those two consecutive openReader calls redundant or needed?
that was a very bad bug, thank you for catching that.
bq. Andrzej - does ScriptFile now address your needs with it being
ResourceLoader savvy? I'm not sure it does - I think you were asking for
scripts to be loaded from the factory configuration directly? Just checking if
we're still missing a use case Andrzej had in mind.
We are most definitely missing what ab was asking about -- i was alluding to
his comments when i mentioned that we should probably iterate on other script
based updateprocessors that scope things differently and have longer life
cycles. The fact that we do *not* attempt to cache the bytes of the file is
one way this processor is "stateless" because you can actually edit the script
files w/o needing a core reload and your changes automaticly get picked up.
The majority of what is in this factory is really around dealing with parsing
init args and dealing with script files. The amount of code needed to interact
with teh ScriptEngineManager and ScriptEngines is so tiny it seems like what
he's describing could be done just as easily with a completely distinct
processor then worrying about extending this one -- hence i didn't worry about
making ScriptFile or EngineInfo public (but who knows, maybe if/when we iterate
on other versions, we'll find that a lot of this can be refactored into a
baseclass)
bq. So at the very least, the .js scripts should all be fully fleshed out to
what would work for real.
good catch .. i thought i already did that.
bq. But I really think we should default to no-op on all methods that don't
exist when tried to invoke. Is that so bad?
I think it would be horrific. Consider a small typo in your example...
{code}
def processadd(cmd)
doc = cmd.solrDoc
doc.addField('foo_s', 'bar')
$logger.info("Added field to #{doc}")
end
{code}
...it will silently do nothing, which is terrible.
I would rather people have to write a few no-op methods and get good errors
then rip their hair out -- or have data loss -- because they have a subtle typo
in a function name that they don't notice
---
Updated patch fixes the double reader open and adds the NOOP methods to all
example scripts (except for "missing.functions.updateprocessor.js" because
that's the entire point of the file)
> 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,
> SOLR-1725.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: [email protected]
For additional commands, e-mail: [email protected]
