[
https://issues.apache.org/jira/browse/SOLR-2823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13125890#comment-13125890
]
Erik Hatcher edited comment on SOLR-2823 at 10/12/11 2:44 PM:
--------------------------------------------------------------
bq. Bean declarations in Spring also come to mind. Are we able to leverage any
existing implementations / ideas?
perish the thought! :)
My fairly snarky comment about recreating an "Ant" container for very rich bean
setting and executing capabilities was a bit hyperbolic.
Next someone will want an :
{code}
<if test="${doc.langid} == 'xyz'">
<next-processor-chain/>
<else>
<a-different-processor-chain/>
</else>
</if>
{code}
:)
So... (and I'm not proposing this since I've not got an implementation to
contribute, but bits and pieces of it already are): a ScriptProcessor
mechanism, so that when you need logic and code you can, umm, write some code.
{code}
my_update_processor.rb
----------------------
# totally contrived example and syntax
LogUpdateProcessor docs
case command
when :add
docs.each { |doc|
LangIdProcessor doc, {:lang_id = '... options ...'}
if doc[:lang] == 'fr'
SpecialFrenchProcessor doc
doc[:special] = true
else
NonFrenchProcessor doc
end
end
next.process_add
when :delete
next.process_delete
else
next # or raise "Unsupported command"
end
RunUpdateProcessor docs
{code}
Anyway, you can see where I'm coming from with that example (regardless of
contrived "DSL").
In other words, this XML nonsense for configuration is a slippery slope.
was (Author: ehatcher):
bq. Bean declarations in Spring also come to mind. Are we able to leverage
any existing implementations / ideas?
perish the thought! :)
My fairly snarky comment about recreating an "Ant" container for very rich bean
setting and executing capabilities was a bit hyperbolic.
Next someone will want an :
{code}
<if test="${doc.langid} == 'xyz'">
<next-processor-chain/>
<else>
<a-different-processor-chain/>
</if>
{code}
:)
So... (and I'm not proposing this since I've not got an implementation to
contribute, but bits and pieces of it already are): a ScriptProcessor
mechanism, so that when you need logic and code you can, umm, write some code.
{code}
my_update_processor.rb
----------------------
# totally contrived example and syntax
LogUpdateProcessor docs
case command
when :add
docs.each { |doc|
LangIdProcessor doc, {:lang_id = '... options ...'}
if doc[:lang] == 'fr'
SpecialFrenchProcessor doc
doc[:special] = true
else
NonFrenchProcessor doc
end
end
next.process_add
when :delete
next.process_delete
else
next # or raise "Unsupported command"
end
RunUpdateProcessor docs
{code}
Anyway, you can see where I'm coming from with that example (regardless of
contrived "DSL").
In other words, this XML nonsense for configuration is a slippery slope.
> Re-use of UpdateProcessor configurations in multiple UpdateChains
> -----------------------------------------------------------------
>
> Key: SOLR-2823
> URL: https://issues.apache.org/jira/browse/SOLR-2823
> Project: Solr
> Issue Type: Improvement
> Components: update
> Reporter: Jan Høydahl
> Priority: Minor
>
> When dealing with multiple UpdateChains and Processors, you frequently need
> to re-use configuration. Two chains may be equal except for one config
> setting in one <processor>.
> I propose to allow named processor configs, which can be referenced by name
> in the chains.
--
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
