[
https://issues.apache.org/jira/browse/SOLR-2802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13118565#comment-13118565
]
Jan Høydahl commented on SOLR-2802:
-----------------------------------
I think <copyField> should still remain in Schema, as it is often very tight
linked with things like copying fields for spellcheck or creating a facet field
for an analyzed field. Thus, it is much more clear when that config is
distributed together in the schema, instead of as a processor config, causing
the schema design to fail if user selects another update.chain than the one you
expected etc. FieldCopy processor is made to copy, concatenate or rename fields
because you may need a fieldCopy in the context of one update.chain, but maybe
not in the context of another one.
My vision (which I'll also address in Barcelona) is to improve the updateChain
architecture in several ways, one is that script processors (SOLR-1725) become
first-class citizen processors.
> Toolkit of UpdateProcessors for modifying document values
> ---------------------------------------------------------
>
> Key: SOLR-2802
> URL: https://issues.apache.org/jira/browse/SOLR-2802
> Project: Solr
> Issue Type: New Feature
> Reporter: Hoss Man
> Attachments: SOLR-2802_update_processor_toolkit.patch
>
>
> Frequently users ask about questions about things where the answer is "you
> could do it with an UpdateProcessor" but the number of our of hte box
> UpdateProcessors is generally lacking and there aren't even very good base
> classes for the common case of manipulating field values when adding documents
--
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
