[
https://issues.apache.org/jira/browse/SOLR-6892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14259430#comment-14259430
]
Yonik Seeley commented on SOLR-6892:
------------------------------------
We shouldn't let too much implementation leak into the interface.
DistribUpdateProcessor, etc, are much more implementation than interface. For
example, should one need to know that DistribUpdateProcessor is needed for
atomic updates? What if it's split into two processors in the future?
Likewise for schemaless - it's currently implemented as a whole bunch of
processors, but I could see it moving to a single processor in the future.
It's implementation. People should not be specifying this stuff on requests.
bq. For example, there should be an easy way to query all the pre-configured
components.
Perhaps that's all this feature should be... a way to add additional named
processors to the chain. That should be relatively safe.
> Make update processors toplevel components
> -------------------------------------------
>
> Key: SOLR-6892
> URL: https://issues.apache.org/jira/browse/SOLR-6892
> Project: Solr
> Issue Type: Bug
> Reporter: Noble Paul
> Assignee: Noble Paul
>
> The current update processor chain is rather cumbersome and we should be able
> to use the updateprocessors without a chain.
> The scope of this ticket is
> * <updateProcessor> tag becomes a toplevel tag and it will be equivalent to
> the <processor> tag inside <updateRequestProcessorChain> . The only
> difference is that it should require a {{name}} attribute
> * Any update request will be able to pass a param {{processor=a,b,c}} ,
> where a,b,c are names of update processors. A just in time chain will be
> created with those update processors
> * Some in built update processors (wherever possible) will be predefined with
> standard names and can be directly used in requests
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
