[
https://issues.apache.org/jira/browse/SOLR-6770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14258381#comment-14258381
]
Yonik Seeley commented on SOLR-6770:
------------------------------------
bq. I have separate commands to avoid accidental overwrite. It is just to idiot
proof the system.
I understand the rational, but I just wonder if it makes it easier or harder to
use in practice. This actually creates another mode of failure.
As an example, a common "idiot"/newbie mistake to make may now be:
1) send in a "create" command
2) try it out... yay, it works.
3) modify the command a bit and send it in again... failure? Arg... I have to
use a *different* command if it already exists?
Look at our APIs for adding documents... by default it's a create that replaces
any existing document.
Obviously, the right default semantics depend on the API and expected
use-cases. But I can't think of realistic use-cases when I want to add a param
set but I want it to fail if it already exists.
> Add/edit param sets and use them in Requests
> --------------------------------------------
>
> Key: SOLR-6770
> URL: https://issues.apache.org/jira/browse/SOLR-6770
> Project: Solr
> Issue Type: Sub-task
> Reporter: Noble Paul
> Assignee: Noble Paul
> Fix For: Trunk
>
> Attachments: SOLR-6770.patch, SOLR-6770.patch, SOLR-6770.patch
>
>
> Make it possible to define paramsets and use them directly in requests
> example
> {code}
> curl http://localhost:8983/solr/collection1/config/params -H
> 'Content-type:application/json' -d '{
> "create" : {"x": {
> "a":"A val",
> "b": "B val"}
> },
> "update" : {"y": {
> "x":"X val",
> "Y": "Y val"}
> },
> "modify" : {"y": {
> "x":"X val modified"}
> },
> "delete" : "z"
> }'
> #do a GET to view all the configured params
> curl http://localhost:8983/solr/collection1/config/params
> #or GET with a specific name to get only one set of params
> curl http://localhost:8983/solr/collection1/config/params/x
> {code}
> This data will be stored in conf/params.json
> This is used requesttime and adding/editing params will not result in core
> reload and it will have no impact on the performance
> example usage http://localhost/solr/collection/select?useParams=x,y
> or it can be directly configured with a request handler as follows
> {code}
> <requestHandler name="/dump1" class="DumpRequestHandler" useParams="x"/>
> {code}
> {{useParams}} specified in request overrides the one specified in
> {{requestHandler}}
--
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
