lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (SOLR-1725) Script based UpdateRequestProcessorFactory
Date Tue, 03 Jul 2012 01:09:58 GMT

     [ 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message