[jira] [Commented] (SOLR-6892) Make it possible to define update request processors as toplevel components
[
https://issues.apache.org/jira/browse/SOLR-6892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14265803#comment-14265803
]
Ramkumar Aiyengar commented on SOLR-6892:
-
+1 especially for having separate interfaces for the distrib (leader) and
non-distrib (replica) cases, currently the two are entangled in too many places
leading to lot of inefficiencies and inflexibility. I am trying to do this off
and on for SearchComponent and realising how big a mess it currently is..
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: Improvement
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6892) Make it possible to define update request processors as toplevel components
[
https://issues.apache.org/jira/browse/SOLR-6892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14265037#comment-14265037
]
Alexandre Rafalovitch commented on SOLR-6892:
-
I don't mind the new approach to be a super-set of the old one with a new and
better syntax. I just was asking the questions to ensure I understand how the
old use cases map to this new approach.
Is the plan for this to go into 5? Or trunk only?
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: Improvement
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6892) Make it possible to define update request processors as toplevel components
[
https://issues.apache.org/jira/browse/SOLR-6892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14265059#comment-14265059
]
Noble Paul commented on SOLR-6892:
--
[~arafalov] I'm glad that you are asking the right questions
This is not a 5.0 feature. This will only be taken up post 5.0. I'm just
getting the design right
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: Improvement
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6892) Make it possible to define update request processors as toplevel components
[
https://issues.apache.org/jira/browse/SOLR-6892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14265061#comment-14265061
]
Alexandre Rafalovitch commented on SOLR-6892:
-
For post 5.0 (with more time) I would also check what the other methods in the
updates are doing. I have a feeling they are super dark-arts somehow.
Especially with SolrCloud.
As a test, it would be really nice to have a Debug URP that would actually be
able to trace changes happening through each step of URP. Similar to the
Analysis screen of Admin UI.
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: Improvement
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6892) Make it possible to define update request processors as toplevel components
[
https://issues.apache.org/jira/browse/SOLR-6892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14264848#comment-14264848
]
Noble Paul commented on SOLR-6892:
--
We have a fairly complex system in the URP chain. It has ported very badly from
the standalone to solrcloud The problem is the current configuration is not
capable of capturing the various usecases
We have most of the logic hidden behind the scenes and not possible for users
to manipulate.
In short there are three kind of URPs possible.
* pre.processor : The chain that is executed at the node where the request is
received
* processor : Invoked at the leader before the DistributedUpdateProcessor is
invoked
* post processor : Invoked in all replicas before the RunUpdateProcessor is
invoked
All these can be separate chains passed on the the UpdateRequestHandlers .
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: Improvement
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6892) Make it possible to define update request processors as toplevel components
[
https://issues.apache.org/jira/browse/SOLR-6892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14264872#comment-14264872
]
Shalin Shekhar Mangar commented on SOLR-6892:
-
{quote}
processor : Invoked at the leader before the DistributedUpdateProcessor is
invoked
post processor : Invoked in all replicas before the RunUpdateProcessor is
invoked
{quote}
Just to clarify this a bit more:
* processor : Invoked at the leader before the DistributedUpdateProcessor is
invoked _and not at all on the replicas_
* post processor : Invoked in all replicas before the RunUpdateProcessor is
invoked _including the leader_
I agree that the current model is broken. Also see SOLR-2822, SOLR-3473 and
SOLR-4016 for more history and related issues.
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: Improvement
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6892) Make it possible to define update request processors as toplevel components
[
https://issues.apache.org/jira/browse/SOLR-6892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14264886#comment-14264886
]
Alexandre Rafalovitch commented on SOLR-6892:
-
Two questions:
1. How do these three stages express themselves in the current URP chain? I
thought there were only two stages (pre- and post- DistributedUpdateProcessor.
Not sure where the third stage happens.
2. How does this work with atomic updates. My understand was that it is
possible to run URP on sent-only version of the document or on sent-and-loaded
version. So, the URP can update a field based on some other field that may or
may not have been updated in the update request. But I am not clear whether
this boundary is the same or different from one of the 3 boundaries mentioned
in this JIRA.
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: Improvement
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6892) Make it possible to define update request processors as toplevel components
[
https://issues.apache.org/jira/browse/SOLR-6892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14264895#comment-14264895
]
Shalin Shekhar Mangar commented on SOLR-6892:
-
bq. How do these three stages express themselves in the current URP chain? I
thought there were only two stages (pre- and post- DistributedUpdateProcessor.
Not sure where the third stage happens.
I think Noble is talking about the concept of URP and not actual existing
implementations. The current URP chains are carried over from the non-cloud
Solr days and it was modified to support pre/post processing by making
DistribUpdateProcessor as a special marker processor. We should try to
re-imagine this feature as a fresh one and try to accommodate all use-cases and
make them easy to use as well.
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: Improvement
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6892) Make it possible to define update request processors as toplevel components
[
https://issues.apache.org/jira/browse/SOLR-6892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14264905#comment-14264905
]
Noble Paul commented on SOLR-6892:
--
bq.I thought there were only two stages (pre- and post-
DistributedUpdateProcessor
The pre processor mentioned above is not possible in the current URP chain.
This is a new feature only
bq.How do these three stages express themselves in the current URP chain
I'm not sure we should have the new features added to the old syntax and it
does not fit very well there.
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: Improvement
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6892) Make it possible to define update request processors as toplevel components
[
https://issues.apache.org/jira/browse/SOLR-6892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14264913#comment-14264913
]
Shalin Shekhar Mangar commented on SOLR-6892:
-
bq. How does this work with atomic updates. My understand was that it is
possible to run URP on sent-only version of the document or on sent-and-loaded
version. So, the URP can update a field based on some other field that may or
may not have been updated in the update request. But I am not clear whether
this boundary is the same or different from one of the 3 boundaries mentioned
in this JIRA.
Good point. I guess the pre-processor and processor chains as Noble outlined
can only apply on sent-only versions. The post-processor applies on
sent-and-loaded documents.
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: Improvement
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6892) Make it possible to define update request processors as toplevel components
[
https://issues.apache.org/jira/browse/SOLR-6892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6892) Make it possible to define update request processors as toplevel components
[
https://issues.apache.org/jira/browse/SOLR-6892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14259670#comment-14259670
]
Noble Paul commented on SOLR-6892:
--
[~jkrupan]
A lot of your suggestions are not realy in the scope of this ticket and should
be addressed separately
bq. 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.
I think having choices is not really good if it doesn't offer anything better.
bq.Consider a single-processor parameter with the option to specify the
parameters for that processor.
This is just too complex to handle with the flat http parameter structure.
Again beyond the scope
URPs are really powerful but they are a bit hard to configure and use. I wish
to make it easier and more widely used. That is the objective of this ticket
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
