lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jack Krupansky (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-6892) Make it possible to define update request processors as toplevel components
Date Sun, 28 Dec 2014 15:57:13 GMT

    [ https://issues.apache.org/jira/browse/SOLR-6892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14259665#comment-14259665
] 

Jack Krupansky commented on SOLR-6892:
--------------------------------------

Thanks for the description updates. Comments...

1. We need to be explicit about how and when the hard-wired processors are invoked. In particular
the "run update" processor. The "log update" processor is somewhat special in that it is not
mandatory, but a lot of people are not explicitly aware of it, so if they leave it out, they
will be wondering why they don't get logging of updates.

2. I suggest three parameters: "pre.processors" to specify processors before the default chain,
"post.processors" to specify processors after the default chain (before or after "run update"
and "log update"??), and "processors" to specify a processor list to completely replace the
default chain.

3. Make "log update" be automatically added at the end unless a "nolog" processor is specified.

4. Make "run update" be automatically added at the end unless a "norun" processor is specified.

5. Discuss "processor" vs. "processors" - I prefer the latter since it is explicit, but maybe
allow both since the singular/plural can be confusing.

6. Consider supporting both a single parameter with a csv list as well as multiple parameters
each with a single value. I prefer having the choice. Having a separate parameter for each
processor can be more explicit sometimes.

7. Consider a single-processor parameter with the option to specify the parameters for that
processor. That would make it possible to invoke the various field mutating update processors,
which would be especially cool and convenient.


> Make it possible to define update request processors as 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 
> * A new tag <updateProcessor>  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. The {{<updateProcessorChain>}}
tag will continue to exist and it should be possible to define <processor> inside as
well . It should also be possible to reference a named URP in a chain.
> * 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 URPs
> * Some in built update processors (wherever possible) will be predefined with standard
names and can be directly used in requests 
> * What happens when I say processor=a,b,c in a request? It will execute the default chain
after the just-in-time chain {{a->b->c}} . 
> * How to execute a different chain other than the default chain? the same old mechanism
of update.chain=x means that the chain  {{x}} will be applied after {{a,b,c}}
> * How to avoid the default processor chain from being executed ? There will be an implicit
URP called {{STOP}} . send your request as processor=a,b,c,STOP. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message