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

Alexandre Rafalovitch commented on SOLR-6607:
---------------------------------------------

I think it is very important to have unified way to get all the different 
permutations of *ground truth*. Prior to these - exciting - new developments, 
there was one place to find the ground truth - in solrconfig.xml. You could 
grep the file and get everything you needed (well, except for admin ones, but 
they were mentioned in the comments).

But now, we have a lot more handlers that are implicit plus the hardcoded ones 
and the overlay ones. If there is no way to get all of the information 
(including the source of the definition) in one place, there will be confusion 
down the line. From users and - I suspect - tool writers.

So, I think a single end-point with parameters to differentiate the source 
would be nice. The parameters could be ?source=all, source=implicit, 
source=defined, source=overlay as well as status=active, status=overriden and 
status=disabled/inactive (maybe). By default, it would be source=all and 
status=active. These two parameters would be included for each entry.

So, if I have _/selectAR_ in solrconfig.xml and it's also overriden in the 
overlay then it will be returned as *source=overlay*, *status=active* when I 
request with *source=all*, but as *source=defined*, *status=overriden* when I 
request with *source=defined*.

Does it make sense? 



> Managing requesthandlers through API
> ------------------------------------
>
>                 Key: SOLR-6607
>                 URL: https://issues.apache.org/jira/browse/SOLR-6607
>             Project: Solr
>          Issue Type: Sub-task
>            Reporter: Noble Paul
>            Assignee: Noble Paul
>             Fix For: 5.0, Trunk
>
>         Attachments: SOLR-6607.patch
>
>
> The concept of solrconfig editing is split into multiple pieces . This issue 
> is about registering components and uploading binaries through an API.
> This supports multiple operations
>  * commands  'create-requesthandler', 
> "update-requesthandler","delete-requesthandler"  which can set the 
> configuration of a component . This configuration will be saved inside the 
> configoverlay.json
> The components has to be available in the classpath of all nodes. 
> example for registering a component
> {code}
> curl http://localhost:8983/solr/collection1/config -H  -d '{
> "create-requesthandler" : {"name": "/mypath" ,
>                                           "class":"com.mycomponent.ClassName" 
> , 
>                                            "defaults":{"x":"y" ," a":"b"}
>                                          },
> "update-requesthandler" :{"name": "/mypath" ,
>                                            
> "class":"com.mycomponent.ClassName" ,
>                                            "startup":"lazy" ,
>                                            "defaults":{"x":"y" ," a":"b"}
>                                          },
> "delete-requesthandler" :"/mypath" 
> }'
> {code}



--
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

Reply via email to