[jira] [Comment Edited] (SOLR-6594) deprecate the one action only APIs for schema editing

["Noble Paul (JIRA)" <ji...@apache.org>]

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

Noble Paul edited comment on SOLR-6594 at 10/14/14 5:15 PM:
------------------------------------------------------------

There are already many end points in schema API which are not editable . It is OK in REST to have some end points which are GET only and other 'verbs' are disabled . 

I would even go as far to say that the individual end points were made necessary because of the write path requirements. Users would not find it a lot difficult to extract the required data from the whole schema also.  

It may be more weird to have multiple ways to perform the exact same operation. It will put a heavy burden on future developers to ensure that the same functionality is implemented in both end points and they are also consistent. 

I can't imagine what value add will a user get in doing the following 
{code}
curl http://localhost:8983/solr/collection1/schema/fields -X POST -H 'Content-type:application/json' --data-binary '
[
    {
        "name":"department",
        "type":"string",
        "docValues":"true",
        "default":"no department",
        "copyFields": [ "catchall" ]
    }
]'
{code}
instead of

{code}
curl http://localhost:8983/solr/collection1/schema -X POST -H 'Content-type:application/json' --data-binary '
{
    "add-field" : {
        "name":"department",
        "type":"string",
        "docValues":"true",
        "default":"no department",
        "copyFields": [ "catchall" ]
    }
}
{code}

I would say this is more code (25 java files) to maintain for the future developers and more APIs to support. 



was (Author: noble.paul):
There are already many end points in schema API which are not editable . It is OK in REST to have some end points which are GET only and other 'verbs' are disabled . 

It may be more weird to have multiple ways to perform the exact same operation. It will put a heavy burden on future developers to ensure that the same functionality is implemented in both end points and they are also consistent. 

I can't imagine what value add will a user get in doing the following 
{code}
curl http://localhost:8983/solr/collection1/schema/fields -X POST -H 'Content-type:application/json' --data-binary '
[
    {
        "name":"department",
        "type":"string",
        "docValues":"true",
        "default":"no department",
        "copyFields": [ "catchall" ]
    }
]'
{code}
instead of

{code}
curl http://localhost:8983/solr/collection1/schema -X POST -H 'Content-type:application/json' --data-binary '
{
    "add-field" : {
        "name":"department",
        "type":"string",
        "docValues":"true",
        "default":"no department",
        "copyFields": [ "catchall" ]
    }
}
{code}

I would say this is more code (25 java files) to maintain for the future developers and more APIs to support. 


> deprecate the one action only APIs for schema editing
> -----------------------------------------------------
>
>                 Key: SOLR-6594
>                 URL: https://issues.apache.org/jira/browse/SOLR-6594
>             Project: Solr
>          Issue Type: Bug
>            Reporter: Noble Paul
>
> with SOLR-6476 done and committed , we have more than one way of writing to schema . Having two different ways of doing the same thing is counter productive . 
> I would like to mark them as deprecated and the calls to those APIs will succeed but will give a deprecation message in the output.  The read APIs would continue to be the same , though .



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