Solr
  1. Solr
  2. SOLR-6594

deprecate the one action only APIs for schema editing

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 5.5, 6.0
    • Component/s: None
    • Labels:
      None

      Description

      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 .

      Details: the following operations have been deprecated as of Solr 5.5, and support for them will be removed in Solr 6.0:

      • Create new field(s): POST to /collection/schema/fields or PUT to /collection/schema/fields/fieldname
      • Create new dynamic field(s): POST to /collection/schema/dynamicfields or PUT to /collection/schema/dynamicfields/glob
      • Create new field type(s): POST to /collection/schema/fieldtypes or PUT to /collection/schema/fieldtypes/name
      • Create new copyField rule(s): POST to /collection/schema/copyfields.

      Note that all of the above operations can instead be performed using the bulk schema API, documented since the 5.0 Solr ref guide here: https://cwiki.apache.org/confluence/display/solr/Schema+API

      To be clear, read-only GET operations on the above-mentioned endpoints will not be changed, deprecated or removed - they will continue to return information about fields, dynamicFields, fieldTypes, and copyField rules, respectively.

        Issue Links

          Activity

          Hide
          Shalin Shekhar Mangar added a comment -

          +1

          We are close to a 5.0 release so we should start deprecating the other APIs.

          Show
          Shalin Shekhar Mangar added a comment - +1 We are close to a 5.0 release so we should start deprecating the other APIs.
          Hide
          Steve Rowe added a comment -

          I think it would be very weird from the Schema API consumers' POV to remove existing write access while leaving read access in place for the fine-grained endpoints.

          Also, having separate read- and write-side REST API endpoints seems bad to me.

          Show
          Steve Rowe added a comment - I think it would be very weird from the Schema API consumers' POV to remove existing write access while leaving read access in place for the fine-grained endpoints. Also, having separate read- and write-side REST API endpoints seems bad to me.
          Hide
          Noble Paul added a comment - - edited

          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

          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" ]
              }
          ]'
          

          instead of

          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" ]
              }
          }
          

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

          Show
          Noble Paul added a comment - - edited 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 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" ] } ]' instead of 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" ] } } I would say this is more code (25 java files) to maintain for the future developers and more APIs to support.
          Hide
          Shalin Shekhar Mangar added a comment -

          I believe that a simple bulk API can satisfy all requirements for a schema API and we should no longer attempt to have additional fine-grained end points for writes. I am not against fine-grained read endpoints but even that can be satisfied by a bulk API which allows filtering. In future, I wouldn't want to write/maintain APIs for bulk and individual operations – I'm assuming a config API will probably add at least ten fine-grained APIs if we go that way.

          Show
          Shalin Shekhar Mangar added a comment - I believe that a simple bulk API can satisfy all requirements for a schema API and we should no longer attempt to have additional fine-grained end points for writes. I am not against fine-grained read endpoints but even that can be satisfied by a bulk API which allows filtering. In future, I wouldn't want to write/maintain APIs for bulk and individual operations – I'm assuming a config API will probably add at least ten fine-grained APIs if we go that way.
          Hide
          Timothy Potter added a comment -

          +1 ... I'd like to see the code get cleaned up to just use the bulk API with a "shim" that maps the old endpoints to the bulk API automatically. The shim should be deprecated but left in-place for a while existing apps that use the specific endpoints and responses from the fine-grained endpoints should include a deprecation warning.

          New functionality should only be implemented in the bulk API.

          Show
          Timothy Potter added a comment - +1 ... I'd like to see the code get cleaned up to just use the bulk API with a "shim" that maps the old endpoints to the bulk API automatically. The shim should be deprecated but left in-place for a while existing apps that use the specific endpoints and responses from the fine-grained endpoints should include a deprecation warning. New functionality should only be implemented in the bulk API.
          Hide
          ASF subversion and git services added a comment -

          Commit 2184a7baf6e47f99b7a637836a736c3439b69125 in lucene-solr's branch refs/heads/master from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2184a7b ]

          SOLR-6594 Mark old schema APIs as deprecated

          Show
          ASF subversion and git services added a comment - Commit 2184a7baf6e47f99b7a637836a736c3439b69125 in lucene-solr's branch refs/heads/master from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2184a7b ] SOLR-6594 Mark old schema APIs as deprecated
          Hide
          ASF subversion and git services added a comment -

          Commit 890497b08184688361d0e9c2dd0725d9117dca12 in lucene-solr's branch refs/heads/branch_5x from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=890497b ]

          SOLR-6594 Mark old schema APIs as deprecated

          Show
          ASF subversion and git services added a comment - Commit 890497b08184688361d0e9c2dd0725d9117dca12 in lucene-solr's branch refs/heads/branch_5x from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=890497b ] SOLR-6594 Mark old schema APIs as deprecated
          Hide
          Noble Paul added a comment -

          To be clear, read-only GET operations on the above-mentioned endpoints will not be changed, deprecated or removed - they will continue to return information about fields, dynamicFields, fieldTypes, and copyField rules, respectively.

          We need to add these support . I have opened SOLR-8736

          Show
          Noble Paul added a comment - To be clear, read-only GET operations on the above-mentioned endpoints will not be changed, deprecated or removed - they will continue to return information about fields, dynamicFields, fieldTypes, and copyField rules, respectively. We need to add these support . I have opened SOLR-8736

            People

            • Assignee:
              Unassigned
              Reporter:
              Noble Paul
            • Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development