Uploaded image for project: 'Solr'
  1. Solr
  2. SOLR-8029

Modernize and standardize Solr APIs

    Details

    • Type: Improvement
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 6.0
    • Fix Version/s: 6.5, 7.0
    • Component/s: None
    • Labels:

      Description

      Solr APIs have organically evolved and they are sometimes inconsistent with each other or not in sync with the widely followed conventions of HTTP protocol. Trying to make incremental changes to make them modern is like applying band-aid. So, we have done a complete rethink of what the APIs should be. The most notable aspects of the API are as follows:
      The new set of APIs will be placed under a new path /solr2. The legacy APIs will continue to work under the /solr path as they used to and they will be eventually deprecated.
      There are 4 types of requests in the new API

      • /v2/<collection-name>/* : Hit a collection directly or manage collections/shards/replicas
      • /v2/<core>/* : Hit a core directly or manage cores
      • /v2/cluster/* : Operations on cluster not pertaining to any collection or core. e.g: security, overseer ops etc

      This will be released as part of a major release. Check the link given below for the full specification. Your comments are welcome
      Solr API version 2 Specification

      1. SOLR-8029.patch
        355 kB
        Noble Paul
      2. SOLR-8029.patch
        178 kB
        Noble Paul
      3. SOLR-8029.patch
        180 kB
        Noble Paul
      4. SOLR-8029.patch
        172 kB
        Noble Paul
      5. SOLR-8029.patch
        170 kB
        Noble Paul

        Issue Links

          Activity

          Hide
          elyograg Shawn Heisey added a comment -

          I have no real wish to derail your plan, but I wondered about a possible wrinkle: In order to have a /solr2 URL work, doesn't that require a completely separate context, and therefore a separate application from Jetty's point of view? If this is true, are there any problems in getting the two to work together? They would be in the same JVM, but for general security concerns I would hope that the servlet API keeps them pretty separate.

          Something to think about ... I wonder if maybe paths under /CONTEXT/api (where CONTEXT is defined in the context fragment for the container and is normally "solr") would be a better way to separate this out. At that point, you could put the new angular UI on /CONTEXT/ui. Having separate and clear URLs for ui and api would make it a lot easier for a user to know that they can't put a ui URL into a program that expects to talk to the api.

          Show
          elyograg Shawn Heisey added a comment - I have no real wish to derail your plan, but I wondered about a possible wrinkle: In order to have a /solr2 URL work, doesn't that require a completely separate context, and therefore a separate application from Jetty's point of view? If this is true, are there any problems in getting the two to work together? They would be in the same JVM, but for general security concerns I would hope that the servlet API keeps them pretty separate. Something to think about ... I wonder if maybe paths under /CONTEXT/api (where CONTEXT is defined in the context fragment for the container and is normally "solr") would be a better way to separate this out. At that point, you could put the new angular UI on /CONTEXT/ui. Having separate and clear URLs for ui and api would make it a lot easier for a user to know that they can't put a ui URL into a program that expects to talk to the api.
          Hide
          noble.paul Noble Paul added a comment -

          Shawn Heisey We could deploy solr at the root context / that means /solr and /solr2 will become paths controlled by Solr.

          The UI could live at a separate path however

          Show
          noble.paul Noble Paul added a comment - Shawn Heisey We could deploy solr at the root context / that means /solr and /solr2 will become paths controlled by Solr. The UI could live at a separate path however
          Hide
          elyograg Shawn Heisey added a comment -

          The path "/solr2" rubs me the wrong way. It implies to a user that we didn't think it through originally, had to change it, and just tacked on a number. We'll be stuck with it forever to avoid future compatibility problems. Users may start to wonder when version 3 will come out and force them to change all their software again. Using something like /solr/api, with all the old paths working until explicitly disabled in the config or the next major version comes out, will look like a well-planned and permanent change to users. If we use "/solr2" it might look like we are quickly fixing a major oops with a temporary URL path that will disappear in a future version.

          I don't like the idea of deploying the context at the root, but it's not a BAD solution if we do it right. If we do that, the URL path should remain configurable, so a user can use /fahrbot if they want to. One problem with this is that suddenly it becomes Solr's responsibility to make sure that path works correctly throughout the application. Jetty has had a very long time to work out any bugs with custom context paths ... we would be starting from scratch.

          I know that we might be starting from scratch with supporting a configurable path when we shed the webapp and become a standalone application, so that part of my thoughts might be moot.

          Show
          elyograg Shawn Heisey added a comment - The path "/solr2" rubs me the wrong way. It implies to a user that we didn't think it through originally, had to change it, and just tacked on a number. We'll be stuck with it forever to avoid future compatibility problems. Users may start to wonder when version 3 will come out and force them to change all their software again . Using something like /solr/api, with all the old paths working until explicitly disabled in the config or the next major version comes out, will look like a well-planned and permanent change to users. If we use "/solr2" it might look like we are quickly fixing a major oops with a temporary URL path that will disappear in a future version. I don't like the idea of deploying the context at the root, but it's not a BAD solution if we do it right. If we do that, the URL path should remain configurable, so a user can use /fahrbot if they want to. One problem with this is that suddenly it becomes Solr's responsibility to make sure that path works correctly throughout the application. Jetty has had a very long time to work out any bugs with custom context paths ... we would be starting from scratch. I know that we might be starting from scratch with supporting a configurable path when we shed the webapp and become a standalone application, so that part of my thoughts might be moot.
          Hide
          upayavira Upayavira added a comment -

          If we are going to go this way, and it will require a lot of consensus for us to do so, we should not be thinking about implementation issues right now.

          I'd ask why Solr2? There never was a solr2. What might make more sense would be http://$host:8983/v2/blah as that would allow us to do future iterations on the API should we decide to (or even http://$host:8983/solr/v2/blah)

          Show
          upayavira Upayavira added a comment - If we are going to go this way, and it will require a lot of consensus for us to do so, we should not be thinking about implementation issues right now. I'd ask why Solr2? There never was a solr2. What might make more sense would be http://$host:8983/v2/blah as that would allow us to do future iterations on the API should we decide to (or even http://$host:8983/solr/v2/blah )
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment -

          If we are going to have this released for 6.0, can we not use /solr context for the new API, but something like /solr-old (or similar) for backcompat reasons?

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - If we are going to have this released for 6.0, can we not use /solr context for the new API, but something like /solr-old (or similar) for backcompat reasons?
          Hide
          noble.paul Noble Paul added a comment - - edited

          if we use "/solr2" it might look like we are quickly fixing a major oops with a temporary URL path that will disappear in a future version.

          Yes, we are doing a quick fix. Because anything else will also will look like a quick fix and api becomes a reserved name which cannot conflict with a collection name. We should not make the new API look like a second class citizen where I need to append an extra path to access that like solr/api/_cluster

          Eventually , when we deprecate the legacy API, we should be able to get rid of the prefix altogether.

          At this point let us not discuss the "how" part. Let's define what an ideal solution should look like and fix that first.

          Show
          noble.paul Noble Paul added a comment - - edited if we use "/solr2" it might look like we are quickly fixing a major oops with a temporary URL path that will disappear in a future version. Yes, we are doing a quick fix. Because anything else will also will look like a quick fix and api becomes a reserved name which cannot conflict with a collection name. We should not make the new API look like a second class citizen where I need to append an extra path to access that like solr/api/_cluster Eventually , when we deprecate the legacy API, we should be able to get rid of the prefix altogether. At this point let us not discuss the "how" part. Let's define what an ideal solution should look like and fix that first.
          Hide
          noble.paul Noble Paul added a comment -

          I know that we might be starting from scratch with supporting a configurable path when we shed the webapp and become a standalone application, so that part of my thoughts might be moot.

          Did we not already get rid of the concept that "solr is a webapp"

          Show
          noble.paul Noble Paul added a comment - I know that we might be starting from scratch with supporting a configurable path when we shed the webapp and become a standalone application, so that part of my thoughts might be moot. Did we not already get rid of the concept that "solr is a webapp"
          Hide
          smolloy Steve Molloy added a comment -

          Having version in URL is pretty common and makes sense to me. The old API could be made into v1, pointing the root /solr to v2 by default, with option to configure it to v1 for people needing to support backward compatibility with absolutely no impact on their existing client applications.

          Show
          smolloy Steve Molloy added a comment - Having version in URL is pretty common and makes sense to me. The old API could be made into v1, pointing the root /solr to v2 by default, with option to configure it to v1 for people needing to support backward compatibility with absolutely no impact on their existing client applications.
          Hide
          noble.paul Noble Paul added a comment -

          The old API could be made into v1, pointing the root /solr to v2 by default, with option to configure it to v1 for people needing to support backward compatibility with absolutely no impact on their existing client applications.

          Changing stuff abruptly will infuriate users. All the existing apps should work when they move to new Solr. If we fail to do that we will hamper adoption. We should give users a painless migration path.

          Show
          noble.paul Noble Paul added a comment - The old API could be made into v1, pointing the root /solr to v2 by default, with option to configure it to v1 for people needing to support backward compatibility with absolutely no impact on their existing client applications. Changing stuff abruptly will infuriate users. All the existing apps should work when they move to new Solr. If we fail to do that we will hamper adoption. We should give users a painless migration path.
          Hide
          upayavira Upayavira added a comment -

          I don't think that's what Steve means.

          http://HOST:8983/v1/blah redirects to http://HOST:8983/solr/blah
          http://HOST:8983/v2/blah does new clever things
          http://HOST:8983/solr/blah does what it ever did

          Decent, versioned API, and backwards compatibility.

          Show
          upayavira Upayavira added a comment - I don't think that's what Steve means. http://HOST:8983/v1/blah redirects to http://HOST:8983/solr/blah http://HOST:8983/v2/blah does new clever things http://HOST:8983/solr/blah does what it ever did Decent, versioned API, and backwards compatibility.
          Hide
          smolloy Steve Molloy added a comment -

          Changing stuff abruptly will infuriate users. All the existing apps should work when they move to new Solr. If we fail to do that we will hamper adoption. We should give users a painless migration path.

          Agreed, this is why I propose to have the current API URL point to the URL with /v1 or /v2 in it. Making the choice of default version configurable would allow people to use the API they want as they were using it in previous version, then start migrating slowly, at their own pace, to the new version by using /v2 URl in client code using new API. Once everything is updated, they could change default version configured and not have to change their client code. With this approach, the same would apply if in some years we decide to have a v3 API for whatever reason.

          Show
          smolloy Steve Molloy added a comment - Changing stuff abruptly will infuriate users. All the existing apps should work when they move to new Solr. If we fail to do that we will hamper adoption. We should give users a painless migration path. Agreed, this is why I propose to have the current API URL point to the URL with /v1 or /v2 in it. Making the choice of default version configurable would allow people to use the API they want as they were using it in previous version, then start migrating slowly, at their own pace, to the new version by using /v2 URl in client code using new API. Once everything is updated, they could change default version configured and not have to change their client code. With this approach, the same would apply if in some years we decide to have a v3 API for whatever reason.
          Hide
          noble.paul Noble Paul added a comment - - edited

          Upayavira So what you are saying is instead of the the prefix /solr2 use the /v2 prefix.

          Show
          noble.paul Noble Paul added a comment - - edited Upayavira So what you are saying is instead of the the prefix /solr2 use the /v2 prefix.
          Hide
          noble.paul Noble Paul added a comment -

          Agreed, this is why I propose to have the current API URL point to the URL with /v1 or /v2 in it.

          need more clarity

          I make the following assumptions in the new design.

          • Every path that exists today should work exactly same in 6.0
          • Using the new API should not have extra long uri which may make it look like a second class citizen
          Show
          noble.paul Noble Paul added a comment - Agreed, this is why I propose to have the current API URL point to the URL with /v1 or /v2 in it. need more clarity I make the following assumptions in the new design. Every path that exists today should work exactly same in 6.0 Using the new API should not have extra long uri which may make it look like a second class citizen
          Hide
          smolloy Steve Molloy added a comment -

          Yes, make the current version:
          /v1/

          {api}

          Make the new version:
          /v2/{api}

          And have /solr point to a configurable version, probably /v1 by default at first:
          /solr/collection/select => /v1/collection/select
          /v1/collection/select => Same as current /solr/collection/select
          /v2/collection/select => New API for collection operations.

          This way, existing clients get the existing behaviour. Client that wish to migrate progressively can use both /solr pointing to /v1 and /v2 in new calls. Completely new clients can either use /v2 or configure Solr so /solr points to /v2 and use that, meaning:

          /solr/collection/select => /v2/collection/select
          /v1/collection/select => current API
          /v2/collection/select => new API.

          Show
          smolloy Steve Molloy added a comment - Yes, make the current version: /v1/ {api} Make the new version: /v2/{api} And have /solr point to a configurable version, probably /v1 by default at first: /solr/collection/select => /v1/collection/select /v1/collection/select => Same as current /solr/collection/select /v2/collection/select => New API for collection operations. This way, existing clients get the existing behaviour. Client that wish to migrate progressively can use both /solr pointing to /v1 and /v2 in new calls. Completely new clients can either use /v2 or configure Solr so /solr points to /v2 and use that, meaning: /solr/collection/select => /v2/collection/select /v1/collection/select => current API /v2/collection/select => new API.
          Hide
          noble.paul Noble Paul added a comment -

          not a bad idea.

          Show
          noble.paul Noble Paul added a comment - not a bad idea.
          Hide
          elyograg Shawn Heisey added a comment -

          I had not considered the idea of a conflict with a collection or core named api. That is a potential problem.

          Forgetting about implementation for the discussion is a good idea, but I think the URL path is important even if we don't consider how we're going to do it. I think that stepping away from the default /solr prefix, especially if that is a temporary change that we then change back in next major version's example, is going really irritate users. I believe that if we are going to change the URL path, it should remain under /solr (or whatever the user chose for the context), and be a permanent move.

          I wonder if you could have the implementation work in such a way that /solr/api/select (and friends) would still work for a collection named api, and /solr/api/api/select (or however we arrange the lower bits of a new structure) would ALSO work. We could also declare (and document) that if the new APIs are enabled, a core named api will no longer be accessible.

          /solr/v2 is another idea, but I do not want anyone to get tied to a specific version in the base URL, and there is still the possibility that a user has a core with a conflicting name.

          Did we not already get rid of the concept that "solr is a webapp"

          We got rid of the concept from the user perspective, but it is still a crucial detail of our implementation. We have talked about changing that, but it is our reality for the moment, and once we get to the implementation, it will have to be factored in.

          I don't want anyone to think that any of my ideas or criticisms are an indication of an automatic -1 vote. I think the general idea here is VERY good, but that the proposed plan could be improved. If everyone disagrees with me, then I will adapt ... and try not to be mean if my concerns become real.

          Show
          elyograg Shawn Heisey added a comment - I had not considered the idea of a conflict with a collection or core named api. That is a potential problem. Forgetting about implementation for the discussion is a good idea, but I think the URL path is important even if we don't consider how we're going to do it. I think that stepping away from the default /solr prefix, especially if that is a temporary change that we then change back in next major version's example, is going really irritate users. I believe that if we are going to change the URL path, it should remain under /solr (or whatever the user chose for the context), and be a permanent move. I wonder if you could have the implementation work in such a way that /solr/api/select (and friends) would still work for a collection named api, and /solr/api/api/select (or however we arrange the lower bits of a new structure) would ALSO work. We could also declare (and document) that if the new APIs are enabled, a core named api will no longer be accessible. /solr/v2 is another idea, but I do not want anyone to get tied to a specific version in the base URL, and there is still the possibility that a user has a core with a conflicting name. Did we not already get rid of the concept that "solr is a webapp" We got rid of the concept from the user perspective, but it is still a crucial detail of our implementation. We have talked about changing that, but it is our reality for the moment, and once we get to the implementation, it will have to be factored in. I don't want anyone to think that any of my ideas or criticisms are an indication of an automatic -1 vote. I think the general idea here is VERY good, but that the proposed plan could be improved. If everyone disagrees with me, then I will adapt ... and try not to be mean if my concerns become real.
          Hide
          noble.paul Noble Paul added a comment -

          solr/v2 is another idea, but I do not want anyone to get tied to a specific version in the base URL, and there is still the possibility that a user has a core with a conflicting name.

          Steve Molloy suggests that we have only /v2 or /v1 prefix instead of the /solr prefix. However /solr prefix would work as if it is equivalent to /v1. Having /v1 or /v2 prefix is extremely common among API designers now. I give a +1 for Steve Molloy 's suggestion . We don't need to tell the user that he is using solr by using it in every API call

          Show
          noble.paul Noble Paul added a comment - solr/v2 is another idea, but I do not want anyone to get tied to a specific version in the base URL, and there is still the possibility that a user has a core with a conflicting name. Steve Molloy suggests that we have only /v2 or /v1 prefix instead of the /solr prefix. However /solr prefix would work as if it is equivalent to /v1 . Having /v1 or /v2 prefix is extremely common among API designers now. I give a +1 for Steve Molloy 's suggestion . We don't need to tell the user that he is using solr by using it in every API call
          Hide
          elyograg Shawn Heisey added a comment -

          I like my idea better, but /v2 would work. I think users aren't going to like it, and I think the only way you can make it really work is to deploy at the root context. The root context means it will be up to solr to make sure that /solr, /v1, and /v2 are all functioning correctly, and I have concerns that we will have a release that's less than stable because of it.

          I've voiced my concerns and elaborated at length on my own ideas, so I'm done for now. Good luck with implementation, and I look forward to seeing it!

          Show
          elyograg Shawn Heisey added a comment - I like my idea better, but /v2 would work. I think users aren't going to like it, and I think the only way you can make it really work is to deploy at the root context. The root context means it will be up to solr to make sure that /solr, /v1, and /v2 are all functioning correctly, and I have concerns that we will have a release that's less than stable because of it. I've voiced my concerns and elaborated at length on my own ideas, so I'm done for now. Good luck with implementation, and I look forward to seeing it!
          Hide
          upayavira Upayavira added a comment -

          I note that there's lot more to this proposal than just the URL - we've missed a heap of content in your proposal document. Can we break it out into JIRAs so we can explore each part?

          e.g. you suggest a GET to /solr2/<collection>/query would execute a search. I'd suggest that the 'query' is unneeded. The point is that, from a REST point of view, the <collection> is the resource we are interacting with, not a 'query'. I'd love to see a venue for discussing these details in, well, detail.

          Show
          upayavira Upayavira added a comment - I note that there's lot more to this proposal than just the URL - we've missed a heap of content in your proposal document. Can we break it out into JIRAs so we can explore each part? e.g. you suggest a GET to /solr2/<collection>/query would execute a search. I'd suggest that the 'query' is unneeded. The point is that, from a REST point of view, the <collection> is the resource we are interacting with, not a 'query'. I'd love to see a venue for discussing these details in, well, detail.
          Hide
          noble.paul Noble Paul added a comment - - edited

          we've missed a heap of content in your proposal document. Can we break it out into JIRAs so we can explore each part?

          I'll eventually create more sub tasks for implementing specific things. But, if I do it now you would not get the complete picture as the doc provides.

          I'd suggest that the 'query' is unneeded.

          I beg to differ. it will be rather awkward to make a request like /v2/gettingstarted?q=fieldname:val . the <collection> means a lot of things. not just the contents of the index

          Show
          noble.paul Noble Paul added a comment - - edited we've missed a heap of content in your proposal document. Can we break it out into JIRAs so we can explore each part? I'll eventually create more sub tasks for implementing specific things. But, if I do it now you would not get the complete picture as the doc provides. I'd suggest that the 'query' is unneeded. I beg to differ. it will be rather awkward to make a request like /v2/gettingstarted?q=fieldname:val . the <collection> means a lot of things. not just the contents of the index
          Hide
          upayavira Upayavira added a comment -

          You are suggesting we write a new RESTful API, then suggesting something that isn't restful. It doesn't make sense to me. A collection doesn't have a property called a 'query'. If you said /<collection>/index?q=:, that might make more sense, because we are querying a collection's index, but a query is more of an action than a resource.

          Show
          upayavira Upayavira added a comment - You are suggesting we write a new RESTful API, then suggesting something that isn't restful. It doesn't make sense to me. A collection doesn't have a property called a 'query'. If you said /<collection>/index?q= : , that might make more sense, because we are querying a collection's index, but a query is more of an action than a resource.
          Hide
          upayavira Upayavira added a comment -

          In case I sound overly negative - I'm not wanting to. This is an interesting proposal that I could support - any criticisms I have are details aimed at making it all stronger, not trying to pull it down.

          Show
          upayavira Upayavira added a comment - In case I sound overly negative - I'm not wanting to. This is an interesting proposal that I could support - any criticisms I have are details aimed at making it all stronger, not trying to pull it down.
          Hide
          noble.paul Noble Paul added a comment -

          You are suggesting we write a new RESTful API

          Nowhere in the document do we suggest that we are making a RESTful API. We don't wan't to conform to any external standard where purists of the standards come and tell us what to do and how to do things. We are making a standard for Solr which is easy for Solr users.

          Show
          noble.paul Noble Paul added a comment - You are suggesting we write a new RESTful API Nowhere in the document do we suggest that we are making a RESTful API. We don't wan't to conform to any external standard where purists of the standards come and tell us what to do and how to do things. We are making a standard for Solr which is easy for Solr users.
          Hide
          upayavira Upayavira added a comment -

          Noble, can you please state some of the rationale behind this proposed API - not in terms of why it is needed, but rather why you have structured it how you have. Why are you using HOCON, which is a largely unknown (to me at least) format over the more widely used JSON? If you are going to want to deviate from REST, which is also a widely implemented standard, I'd like to hear why.

          Show
          upayavira Upayavira added a comment - Noble, can you please state some of the rationale behind this proposed API - not in terms of why it is needed, but rather why you have structured it how you have. Why are you using HOCON, which is a largely unknown (to me at least) format over the more widely used JSON? If you are going to want to deviate from REST, which is also a widely implemented standard, I'd like to hear why.
          Hide
          noble.paul Noble Paul added a comment -

          Hocon is a super set of json. Json is valid hocon. The advantage is that it is not at all strict.

          Show
          noble.paul Noble Paul added a comment - Hocon is a super set of json. Json is valid hocon. The advantage is that it is not at all strict.
          Hide
          wunder Walter Underwood added a comment -

          HOCON looks like a poor choice for a wire format. It is a modified, incompatible JSON designed for human readability.

          Quoting the spec:

          "HOCON is significantly harder to specify and to parse than JSON. Think of it as moving the work from the person maintaining the config file to the computer program."

          https://github.com/typesafehub/config/blob/master/HOCON.md

          If we want a new wire format, we should use something faster, like Protobuf or Avro.

          Show
          wunder Walter Underwood added a comment - HOCON looks like a poor choice for a wire format. It is a modified, incompatible JSON designed for human readability. Quoting the spec: "HOCON is significantly harder to specify and to parse than JSON. Think of it as moving the work from the person maintaining the config file to the computer program." https://github.com/typesafehub/config/blob/master/HOCON.md If we want a new wire format, we should use something faster, like Protobuf or Avro.
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment -

          I think the wire format will continue to remain Javabin and Smile; used between the SolrJ clients and the server.
          For the purpose of API requests, both JSON and HOCON seem decent choices to me.

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - I think the wire format will continue to remain Javabin and Smile; used between the SolrJ clients and the server. For the purpose of API requests, both JSON and HOCON seem decent choices to me.
          Hide
          elyograg Shawn Heisey added a comment -

          I don't have a lot to say about hocon, except that strict json is likely a lot better tested. I've got no experience with it and haven't looked at the spec.

          As for response formats ... the design doc specifically says there will only be json. I predict that javabin will be added back in very quickly for SolrJ. I won't personally miss XML, but some might.

          Show
          elyograg Shawn Heisey added a comment - I don't have a lot to say about hocon, except that strict json is likely a lot better tested. I've got no experience with it and haven't looked at the spec. As for response formats ... the design doc specifically says there will only be json. I predict that javabin will be added back in very quickly for SolrJ. I won't personally miss XML, but some might.
          Hide
          markrmiller@gmail.com Mark Miller added a comment -

          wolfgang hoschek chose HOCON as the config file format for Kite Morphlines. He might have some insights to share around HOCON vs JSON in this context as well.

          Show
          markrmiller@gmail.com Mark Miller added a comment - wolfgang hoschek chose HOCON as the config file format for Kite Morphlines. He might have some insights to share around HOCON vs JSON in this context as well.
          Hide
          noble.paul Noble Paul added a comment -

          The response will continue to support all the existing formats and nothing new. However, hocon will be supported for input commands such as create collection. The objective is to be more forgiving to user typos. Clients such as SolrJ will use json because there will not be any typos and it is easier to produce json than hocon

          Show
          noble.paul Noble Paul added a comment - The response will continue to support all the existing formats and nothing new. However, hocon will be supported for input commands such as create collection. The objective is to be more forgiving to user typos. Clients such as SolrJ will use json because there will not be any typos and it is easier to produce json than hocon
          Hide
          andyetitmoves Ramkumar Aiyengar added a comment -

          The introspect API probably requires this anyway, but all API should be able to statically declare their schema in some format. This would make it possible to plug in encodings which require a schema, like Avro.

          Show
          andyetitmoves Ramkumar Aiyengar added a comment - The introspect API probably requires this anyway, but all API should be able to statically declare their schema in some format. This would make it possible to plug in encodings which require a schema, like Avro.
          Hide
          noble.paul Noble Paul added a comment -

          Ramkumar Aiyengar Can you make this clearer ?

          The introspect API is a like a javadocs for the APIs, which gives you the details of the parameters/constraints/description of each API. I haven't thought about it as a means to define the response. The response will be driven by the wt param

          Show
          noble.paul Noble Paul added a comment - Ramkumar Aiyengar Can you make this clearer ? The introspect API is a like a javadocs for the APIs, which gives you the details of the parameters/constraints/description of each API. I haven't thought about it as a means to define the response. The response will be driven by the wt param
          Hide
          andyetitmoves Ramkumar Aiyengar added a comment -

          Right, my point was to see if we can use it beyond just being a doc, and use it to format the response. The wt param will still drive the encoding/decoding (i.e. json/xml/hocon whatever..), but instead of all APIs just populating and serializing a generic NamedList, it would help to make sure what the APIs return conform to the doc we make available. That way, something like Avro for example, can use the doc as configuration to encode/decode it's data.

          Show
          andyetitmoves Ramkumar Aiyengar added a comment - Right, my point was to see if we can use it beyond just being a doc, and use it to format the response. The wt param will still drive the encoding/decoding (i.e. json/xml/hocon whatever..), but instead of all APIs just populating and serializing a generic NamedList, it would help to make sure what the APIs return conform to the doc we make available. That way, something like Avro for example, can use the doc as configuration to encode/decode it's data.
          Hide
          noble.paul Noble Paul added a comment -

          Do you mean ,the introspect API returns the schema of the output?

          Show
          noble.paul Noble Paul added a comment - Do you mean ,the introspect API returns the schema of the output?
          Hide
          smolloy Steve Molloy added a comment -

          The wt param will still drive the encoding/decoding

          Is there any plans for supporting HTTP Accept header at some point for setting response type?

          Show
          smolloy Steve Molloy added a comment - The wt param will still drive the encoding/decoding Is there any plans for supporting HTTP Accept header at some point for setting response type?
          Hide
          andyetitmoves Ramkumar Aiyengar added a comment -

          Do you mean ,the introspect API returns the schema of the output?

          Schema for both the input and output, yes.

          Show
          andyetitmoves Ramkumar Aiyengar added a comment - Do you mean ,the introspect API returns the schema of the output? Schema for both the input and output, yes.
          Hide
          gerlowskija Jason Gerlowski added a comment -

          The API Spec has a number of TODO comments. Are those the main things you're taking input on at this point, or are you looking for feedback on all aspects of the API?

          Show
          gerlowskija Jason Gerlowski added a comment - The API Spec has a number of TODO comments. Are those the main things you're taking input on at this point, or are you looking for feedback on all aspects of the API?
          Hide
          noble.paul Noble Paul added a comment -

          No. In open to suggestions on anything.not just the todo.

          Show
          noble.paul Noble Paul added a comment - No. In open to suggestions on anything.not just the todo.
          Hide
          gerlowskija Jason Gerlowski added a comment -

          Great, a few quick notes from an initial once-over:

          1.) Is there a reason for the "_" prefix in "/v2/_node" and "/v2/_cluster"? I might be missing some convention here, but it struck me as odd. Is there a reason to not use "/v2/node" and "/v2/cluster" instead?

          2.) Should the Collection APIs have an explicit "_collection" path component (i.e. /v2/_collection/<collection-name>). It seems more consistent with the other two main chunks of the API. The node APIs have "_node" called out explicitly in their base path. The cluster APIs have "_cluster" in their base path as well. Why not do the same for the Collection APIs?

          Show
          gerlowskija Jason Gerlowski added a comment - Great, a few quick notes from an initial once-over: 1.) Is there a reason for the "_" prefix in "/v2/_node" and "/v2/_cluster"? I might be missing some convention here, but it struck me as odd. Is there a reason to not use "/v2/node" and "/v2/cluster" instead? 2.) Should the Collection APIs have an explicit "_collection" path component (i.e. /v2/_collection/<collection-name>). It seems more consistent with the other two main chunks of the API. The node APIs have "_node" called out explicitly in their base path. The cluster APIs have "_cluster" in their base path as well. Why not do the same for the Collection APIs?
          Hide
          jsstylos Jeffrey Stylos added a comment - - edited

          Hi, IBM employee here — we use Solr in our Retrieve and Rank service and are excited about a Solr v2 API to improve the usability of our service.

          Some thoughts on the proposed changes:

          /v2/ is more standard than /solr2/ (looks like others agree)

          Having a path parameter (/v2/[collection]) at the top-level makes it difficult to add new resources or other paths. A more REST-standard approach would be preface path parameters with a static path value (/v2/collections/[collection]). This would also allow the removal of the _ preface on _node and _cluster.

          There is some inconsistency around naming style, with a mixture of snake_case, hyphen-case, camelCase, unseparatedtext, and abbreviations. A v2 API would be a good opportunity to make all of the identifiers use a consistent naming convention.

          On naming, we’ve found in API usability studies that acronyms and abbreviations (like “wt”) make APIs harder to understand.

          HOCON is an interesting suggestion, although I have some concerns about it from a usability standpoint. In our API usability studies one of the most common mistakes using JSON has been attempting to use single quotes instead of double quotes — HOCON doesn’t fix this, and an fact can make things worse by resulting in unexpected behavior ( https://github.com/akka/akka-meta/issues/2 ). By attempting to be more permissive in its parsing, HOCON makes it more difficult for a parser to generate helpful error messages (such as in the common single-quote scenario). Breaking support for existing pretty printers and syntax highlighters is also a concern.

          One suggestion for an additional feature: a version date parameter, ala FourSquare and Stripe, (?version=2015-11-03) would offer greater flexibility in being able to evolve the API without breaking users.

          And finally, a v2 would be a good time to question the core object model and abstractions of the service.

          (For reference, the API guidelines we use for IBM Watson APIs are public at: https://github.com/watson-developer-cloud/api-guidelines.)

          Show
          jsstylos Jeffrey Stylos added a comment - - edited Hi, IBM employee here — we use Solr in our Retrieve and Rank service and are excited about a Solr v2 API to improve the usability of our service. Some thoughts on the proposed changes: /v2/ is more standard than /solr2/ (looks like others agree) Having a path parameter (/v2/ [collection] ) at the top-level makes it difficult to add new resources or other paths. A more REST-standard approach would be preface path parameters with a static path value (/v2/collections/ [collection] ). This would also allow the removal of the _ preface on _node and _cluster. There is some inconsistency around naming style, with a mixture of snake_case, hyphen-case, camelCase, unseparatedtext, and abbreviations. A v2 API would be a good opportunity to make all of the identifiers use a consistent naming convention. On naming, we’ve found in API usability studies that acronyms and abbreviations (like “wt”) make APIs harder to understand. HOCON is an interesting suggestion, although I have some concerns about it from a usability standpoint. In our API usability studies one of the most common mistakes using JSON has been attempting to use single quotes instead of double quotes — HOCON doesn’t fix this, and an fact can make things worse by resulting in unexpected behavior ( https://github.com/akka/akka-meta/issues/2 ). By attempting to be more permissive in its parsing, HOCON makes it more difficult for a parser to generate helpful error messages (such as in the common single-quote scenario). Breaking support for existing pretty printers and syntax highlighters is also a concern. One suggestion for an additional feature: a version date parameter, ala FourSquare and Stripe, (?version=2015-11-03) would offer greater flexibility in being able to evolve the API without breaking users. And finally, a v2 would be a good time to question the core object model and abstractions of the service. (For reference, the API guidelines we use for IBM Watson APIs are public at: https://github.com/watson-developer-cloud/api-guidelines .)
          Hide
          markrmiller@gmail.com Mark Miller added a comment -

          Should the Collection APIs have an explicit "_collection" path component

          It really should. Though the leading underscore stuff looks silly to me. Can we throw in ` too?

          Not having something like this now for cores or collections was a big mistake IMO.

          Show
          markrmiller@gmail.com Mark Miller added a comment - Should the Collection APIs have an explicit "_collection" path component It really should. Though the leading underscore stuff looks silly to me. Can we throw in ` too? Not having something like this now for cores or collections was a big mistake IMO.
          Hide
          noble.paul Noble Paul added a comment -

          A more REST-standard approach would be preface path parameters with a static path value (/v2/collections/[collection]).

          The argument against this suggestion was that the most common operation on solr are read and update . These are collection specific. The cluster and node specific operations are rare . So the idea was to make the commonly used operations shorter

          eg

          /v2/mycollection/update
          /v2/mycollection/select

          instead of

          /v2/collections/mycollection/update
          /v2/collections/mycollection/select

          If we are willing to accept that _node and _cluster are special keywords , then we make the common operations simple which is performed 100's of times every second.

          at the top-level makes it difficult to add new resources or other paths

          All new resources will be added under the /v2/_cluster and /v2/_node paths

          Show
          noble.paul Noble Paul added a comment - A more REST-standard approach would be preface path parameters with a static path value (/v2/collections/ [collection] ). The argument against this suggestion was that the most common operation on solr are read and update . These are collection specific. The cluster and node specific operations are rare . So the idea was to make the commonly used operations shorter eg /v2/mycollection/update /v2/mycollection/select instead of /v2/collections/mycollection/update /v2/collections/mycollection/select If we are willing to accept that _node and _cluster are special keywords , then we make the common operations simple which is performed 100's of times every second. at the top-level makes it difficult to add new resources or other paths All new resources will be added under the /v2/_cluster and /v2/_node paths
          Hide
          markrmiller@gmail.com Mark Miller added a comment -

          To me it's the same silly shortcut arguments that got us the current API mess. If we are redoing it, why make the exact same mistakes?

          If we are willing to accept that _node and _cluster are special keywords

          And if we are willing to accept that future keywords will keep coming and so we are using this prefix '_' as an alternative to the widely accepted URL scoping that we should be doing.

          Show
          markrmiller@gmail.com Mark Miller added a comment - To me it's the same silly shortcut arguments that got us the current API mess. If we are redoing it, why make the exact same mistakes? If we are willing to accept that _node and _cluster are special keywords And if we are willing to accept that future keywords will keep coming and so we are using this prefix '_' as an alternative to the widely accepted URL scoping that we should be doing.
          Hide
          markrmiller@gmail.com Mark Miller added a comment -

          All new resources will be added under the /v2/_cluster and /v2/_node paths

          It's great that someone thinks that now, but it really won't have any meaning to Joe Committer next year. And if it's required over the long haul, it's a real weakness to the design. We have a much more flexible, widely used and understood alternative.

          Show
          markrmiller@gmail.com Mark Miller added a comment - All new resources will be added under the /v2/_cluster and /v2/_node paths It's great that someone thinks that now, but it really won't have any meaning to Joe Committer next year. And if it's required over the long haul, it's a real weakness to the design. We have a much more flexible, widely used and understood alternative.
          Hide
          noble.paul Noble Paul added a comment -

          The argument was that all operations fall under three categories

          • cluster specific
          • node specific
          • collection specific

          If a new resource comes up it has to be one of these so it will be a sub path under these

          Show
          noble.paul Noble Paul added a comment - The argument was that all operations fall under three categories cluster specific node specific collection specific If a new resource comes up it has to be one of these so it will be a sub path under these
          Hide
          gerlowskija Jason Gerlowski added a comment - - edited

          "The argument against this suggestion was that the most common operation on solr are read and update . These are collection specific. The cluster and node specific operations are rare . So the idea was to make the commonly used operations shorter"

          What does making the commonly used paths shorter actually get us?

          Are we trying to keep things shorter to increase readability? If so, I'd argue that it would have the opposite effect. I can only really speak for myself, but I think that the consistency gained by having a static path value (collections, node, cluster) used everywhere outweighs any negatives of having to read an extra path segment.

          Show
          gerlowskija Jason Gerlowski added a comment - - edited "The argument against this suggestion was that the most common operation on solr are read and update . These are collection specific. The cluster and node specific operations are rare . So the idea was to make the commonly used operations shorter" What does making the commonly used paths shorter actually get us? Are we trying to keep things shorter to increase readability? If so, I'd argue that it would have the opposite effect. I can only really speak for myself, but I think that the consistency gained by having a static path value (collections, node, cluster) used everywhere outweighs any negatives of having to read an extra path segment.
          Hide
          noble.paul Noble Paul added a comment - - edited

          Are we trying to keep things shorter to increase readability?

          Yes. readability as well as writability
          I'm not strongly for or against for either. I would like to get others's opinions on this

          Show
          noble.paul Noble Paul added a comment - - edited Are we trying to keep things shorter to increase readability? Yes. readability as well as writability I'm not strongly for or against for either. I would like to get others's opinions on this
          Hide
          smolloy Steve Molloy added a comment -

          I'm +1 for dedicated paths for each resource, in other words, longer paths with collections in it and no special keywords. I personally agree that not having keywords will make things easier to read then having shorter URLs with special keywords.

          Show
          smolloy Steve Molloy added a comment - I'm +1 for dedicated paths for each resource, in other words, longer paths with collections in it and no special keywords. I personally agree that not having keywords will make things easier to read then having shorter URLs with special keywords.
          Hide
          arafalov Alexandre Rafalovitch added a comment -

          +1 for consistency (/collection, /cluster) and for things that will make 3rd party tools play easier with Solr.

          Integration story is important, so sticking to more standard REST guidelines would be more beneficial in long run.

          Show
          arafalov Alexandre Rafalovitch added a comment - +1 for consistency (/collection, /cluster) and for things that will make 3rd party tools play easier with Solr. Integration story is important, so sticking to more standard REST guidelines would be more beneficial in long run.
          Hide
          elyograg Shawn Heisey added a comment -

          Digging around in my pocket for a couple more pennies...

          Consistency is probably the number one goal when an API is redesigned. There better be a REALLY good reason for any deviations that result in special cases, special syntax, etc. I think that /select and /update should NOT have special shorter endpoints, and that identifiers should not have leading underscores (or any other kind of unusual marking) unless they really are some kind of special case that will only be used in highly unusual situations.

          Related tangent: Using "/select" as the default query handler has always seemed like a strange choice to me. Is this an opportunity to rename the default query handler to /query for the v2 api?

          Getting more detailed: It is probably a good idea to have a specific list of legal values for the first URL path component after /v2 ... so only a list like this is valid:

          /v2/collection
          /v2/node
          /v2/cluster
          /v2/core (might need this, if the implementation needs separation from collection)
          

          Standards for the next path component might be different for cluster than they are for collection/node/core ... unless we implement a further abstraction where SolrCloud can be a cluster of clusters.

          Show
          elyograg Shawn Heisey added a comment - Digging around in my pocket for a couple more pennies... Consistency is probably the number one goal when an API is redesigned. There better be a REALLY good reason for any deviations that result in special cases, special syntax, etc. I think that /select and /update should NOT have special shorter endpoints, and that identifiers should not have leading underscores (or any other kind of unusual marking) unless they really are some kind of special case that will only be used in highly unusual situations. Related tangent: Using "/select" as the default query handler has always seemed like a strange choice to me. Is this an opportunity to rename the default query handler to /query for the v2 api? Getting more detailed: It is probably a good idea to have a specific list of legal values for the first URL path component after /v2 ... so only a list like this is valid: /v2/collection /v2/node /v2/cluster /v2/core (might need this , if the implementation needs separation from collection) Standards for the next path component might be different for cluster than they are for collection/node/core ... unless we implement a further abstraction where SolrCloud can be a cluster of clusters.
          Hide
          jsstylos Jeffrey Stylos added a comment -

          One note: for user-created resources, the REST convention is to use the name of the resource in plural `/v2/collections/[collection]` as opposed to `/v2/collection/[collection]`.

          Show
          jsstylos Jeffrey Stylos added a comment - One note: for user-created resources, the REST convention is to use the name of the resource in plural `/v2/collections/ [collection] ` as opposed to `/v2/collection/ [collection] `.
          Hide
          noble.paul Noble Paul added a comment -

          In our API usability studies one of the most common mistakes using JSON has been attempting to use single quotes instead of double quotes

          In Solr you are free to use single quotes or double quotes or no quotes at all. So that does not need hocon

          HOCON will be an optional syntax and default will be JSON (not strict JSON)

          One suggestion for an additional feature: a version date parameter, ala FourSquare and Stripe,

          Solr is a software not a service . SO , I don't know if date makes any sense. We release stuff in parallel. For instance , a bug fix version of 5.3 can be released after 6.0 release. In that case what is the relevance of the date

          And finally, a v2 would be a good time to question the core object model and abstractions of the service.

          Thanks, I shall go through the doc

          Show
          noble.paul Noble Paul added a comment - In our API usability studies one of the most common mistakes using JSON has been attempting to use single quotes instead of double quotes In Solr you are free to use single quotes or double quotes or no quotes at all. So that does not need hocon HOCON will be an optional syntax and default will be JSON (not strict JSON) One suggestion for an additional feature: a version date parameter, ala FourSquare and Stripe, Solr is a software not a service . SO , I don't know if date makes any sense. We release stuff in parallel. For instance , a bug fix version of 5.3 can be released after 6.0 release. In that case what is the relevance of the date And finally, a v2 would be a good time to question the core object model and abstractions of the service. Thanks, I shall go through the doc
          Hide
          jsstylos Jeffrey Stylos added a comment -

          Good point about version dates being more complicated given parallel releases. If version dates don't work directly, I wonder if there's another way to support for minor but breaking API changes that would work better for Solr. Is it setting a minor API version, like ?version=2.004? It would be nice to have a plan for how to introduce small breaking changes apart from going to a new major version.

          Show
          jsstylos Jeffrey Stylos added a comment - Good point about version dates being more complicated given parallel releases. If version dates don't work directly, I wonder if there's another way to support for minor but breaking API changes that would work better for Solr. Is it setting a minor API version, like ?version=2.004? It would be nice to have a plan for how to introduce small breaking changes apart from going to a new major version.
          Hide
          noble.paul Noble Paul added a comment -

          OK +1 to what Shawn Heisey , Mark Miller and Jeffrey Stylos have recommended

          /v2/collections (I am using plural here. not the singular 'collection' )
          /v2/node
          /v2/cluster
          

          But the /v2/core is not there because I assume it is to house the core admin API

          It should be under /v2/node/cores

          I also wish to know where to put the admin UI

          I propose it should be at the same place /admin

          Show
          noble.paul Noble Paul added a comment - OK +1 to what Shawn Heisey , Mark Miller and Jeffrey Stylos have recommended /v2/collections (I am using plural here. not the singular 'collection' ) /v2/node /v2/cluster But the /v2/core is not there because I assume it is to house the core admin API It should be under /v2/node/cores I also wish to know where to put the admin UI I propose it should be at the same place /admin
          Hide
          upayavira Upayavira added a comment -

          Regarding the admin UI, there's two parts:
          1. where is the initial HTML loaded from?
          2. where are the CSS/JS/etc resources loaded from?

          Currently, for #1 it is just at /solr/. A request to / bounces you to /solr/. This could bounce you to /solr/admin/ if preferred.

          Where the CSS/JS/etc is an implementation detail and I'd happily move it (trivially) under a directory such as /admin/, but whilst v1 API is still around we just need to make sure that doesn't conflict with any other /admin APIs (I doubt it would).

          Show
          upayavira Upayavira added a comment - Regarding the admin UI, there's two parts: 1. where is the initial HTML loaded from? 2. where are the CSS/JS/etc resources loaded from? Currently, for #1 it is just at /solr/. A request to / bounces you to /solr/. This could bounce you to /solr/admin/ if preferred. Where the CSS/JS/etc is an implementation detail and I'd happily move it (trivially) under a directory such as /admin/, but whilst v1 API is still around we just need to make sure that doesn't conflict with any other /admin APIs (I doubt it would).
          Hide
          noble.paul Noble Paul added a comment -

          why don't we move all static stuff to a dub directory say /solr/admin/js and /solr/admin/css ? So, we don't need to take up any more root level namespaces

          Show
          noble.paul Noble Paul added a comment - why don't we move all static stuff to a dub directory say /solr/admin/js and /solr/admin/css ? So, we don't need to take up any more root level namespaces
          Hide
          upayavira Upayavira added a comment -

          Isn't that what I just proposed? The static stuff could be hidden under /solr/admin/js, /solr/admin/css, etc, whereas a request to / gets bounced to /solr/admin/, from where the HTML is served.

          Show
          upayavira Upayavira added a comment - Isn't that what I just proposed? The static stuff could be hidden under /solr/admin/js, /solr/admin/css, etc, whereas a request to / gets bounced to /solr/admin/, from where the HTML is served.
          Hide
          noble.paul Noble Paul added a comment - - edited

          cool, then we are on same page. For v2 we should make it work at a path /v2/admin

          Show
          noble.paul Noble Paul added a comment - - edited cool, then we are on same page. For v2 we should make it work at a path /v2/admin
          Hide
          noble.paul Noble Paul added a comment -

          Most of the APIs are done. Poorly tested . Needs a ton of test cases to be added. This is just an early preview

          Show
          noble.paul Noble Paul added a comment - Most of the APIs are done. Poorly tested . Needs a ton of test cases to be added. This is just an early preview
          Hide
          noble.paul Noble Paul added a comment -

          more tests

          Show
          noble.paul Noble Paul added a comment - more tests
          Hide
          noble.paul Noble Paul added a comment -

          more tests

          Show
          noble.paul Noble Paul added a comment - more tests
          Hide
          jkrupan Jack Krupansky added a comment -

          Is this likely to be in 6.0 or 6.1?

          +1 for 6.0, even if not absolutely 100% completely done. At least 6.0 can be billed as having a modern API, even if there might be some additional work required to get it fully rock solid/fully tested in 6.1.

          Show
          jkrupan Jack Krupansky added a comment - Is this likely to be in 6.0 or 6.1? +1 for 6.0, even if not absolutely 100% completely done. At least 6.0 can be billed as having a modern API, even if there might be some additional work required to get it fully rock solid/fully tested in 6.1.
          Hide
          yseeley@gmail.com Yonik Seeley added a comment - - edited

          Whenever it is committed, it would seem to make sense to mark it as experimental, allowing for real user feedback + improvements.

          Show
          yseeley@gmail.com Yonik Seeley added a comment - - edited Whenever it is committed, it would seem to make sense to mark it as experimental, allowing for real user feedback + improvements.
          Hide
          noble.paul Noble Paul added a comment -

          Yes, this will be experimental in the first release. We will have to do a few iterations to get this right

          Show
          noble.paul Noble Paul added a comment - Yes, this will be experimental in the first release. We will have to do a few iterations to get this right
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 1381cc6865e5bed3753f03d7a82ac56298772e18 in lucene-solr's branch refs/heads/apiv2 from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1381cc6 ]

          SOLR-8029 first commit with framework and tests for a few APIs

          Show
          jira-bot ASF subversion and git services added a comment - Commit 1381cc6865e5bed3753f03d7a82ac56298772e18 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1381cc6 ] SOLR-8029 first commit with framework and tests for a few APIs
          Hide
          jira-bot ASF subversion and git services added a comment -

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

          SOLR-8029 Randomly run schema tests with v2 API

          Show
          jira-bot ASF subversion and git services added a comment - Commit acf1a310b40b9e68eadfc21687d7f4b92721a4cc in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=acf1a31 ] SOLR-8029 Randomly run schema tests with v2 API
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 00d985b8eae57fed84423a7a93336de4b22a8f2b in lucene-solr's branch refs/heads/apiv2 from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=00d985b ]

          SOLR-8029 Tests for solrconfig apis now randomly use /v2 endpoints

          Show
          jira-bot ASF subversion and git services added a comment - Commit 00d985b8eae57fed84423a7a93336de4b22a8f2b in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=00d985b ] SOLR-8029 Tests for solrconfig apis now randomly use /v2 endpoints
          Hide
          jira-bot ASF subversion and git services added a comment -

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

          SOLR-8029 added support and test for /update paths. All RequestHandlers now won't be automatically register

          Show
          jira-bot ASF subversion and git services added a comment - Commit b7e51075a02343caa806990a8a5414f2683be615 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b7e5107 ] SOLR-8029 added support and test for /update paths. All RequestHandlers now won't be automatically register
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 8b8c9461f296fb9c4f0f3e3ad9378d50a0244eb2 in lucene-solr's branch refs/heads/apiv2 from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=8b8c946 ]

          SOLR-8029 refactored the SpecProvider API. Addressed a few test failures in async API calls

          Show
          jira-bot ASF subversion and git services added a comment - Commit 8b8c9461f296fb9c4f0f3e3ad9378d50a0244eb2 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=8b8c946 ] SOLR-8029 refactored the SpecProvider API. Addressed a few test failures in async API calls
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 292fe4a19ca96d65a6e0e2bd6213f82371714a4a in lucene-solr's branch refs/heads/apiv2 from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=292fe4a ]

          SOLR-8029 Security API test now randomly uses v2 API

          Show
          jira-bot ASF subversion and git services added a comment - Commit 292fe4a19ca96d65a6e0e2bd6213f82371714a4a in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=292fe4a ] SOLR-8029 Security API test now randomly uses v2 API
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 3cfebd53f66198ec1d738452a688ad4f67dc8436 in lucene-solr's branch refs/heads/apiv2 from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=3cfebd5 ]

          SOLR-8029 renamed class/dirs and removed the 'v2' part

          Show
          jira-bot ASF subversion and git services added a comment - Commit 3cfebd53f66198ec1d738452a688ad4f67dc8436 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=3cfebd5 ] SOLR-8029 renamed class/dirs and removed the 'v2' part
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 346038000e19bad6d3a5a2b9063849b94e897848 in lucene-solr's branch refs/heads/apiv2 from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=3460380 ]

          SOLR-8029 renamed class/dirs and removed the 'v2' part

          Show
          jira-bot ASF subversion and git services added a comment - Commit 346038000e19bad6d3a5a2b9063849b94e897848 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=3460380 ] SOLR-8029 renamed class/dirs and removed the 'v2' part
          Hide
          jira-bot ASF subversion and git services added a comment -

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

          SOLR-8029 removed the V2RequestContext class and folded the functionality into SolrQueryRequest

          Show
          jira-bot ASF subversion and git services added a comment - Commit a4b5c46ff71b569a55f57c1bc5be00b17c36e755 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a4b5c46 ] SOLR-8029 removed the V2RequestContext class and folded the functionality into SolrQueryRequest
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 5893631766d9908de56a714885a23d028add014f in lucene-solr's branch refs/heads/apiv2 from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5893631 ]

          SOLR-8029 By default, do not register all APIs to the v2 path

          Show
          jira-bot ASF subversion and git services added a comment - Commit 5893631766d9908de56a714885a23d028add014f in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5893631 ] SOLR-8029 By default, do not register all APIs to the v2 path
          Hide
          jira-bot ASF subversion and git services added a comment -

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

          SOLR-8029: Merging changes from master

          Show
          jira-bot ASF subversion and git services added a comment - Commit ddeb53dd91cb9370f0f22a4ccdcf33f1e267bf79 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ddeb53d ] SOLR-8029 : Merging changes from master
          Hide
          jira-bot ASF subversion and git services added a comment -

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

          SOLR-8029: Merging changes from master

          Show
          jira-bot ASF subversion and git services added a comment - Commit c0b91afb94387b59eaca699831fedf015879c96b in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c0b91af ] SOLR-8029 : Merging changes from master
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 49b9c62dfb638b2b414a919bff9d391fe8aa2ec5 in lucene-solr's branch refs/heads/apiv2 from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=49b9c62 ]

          SOLR-8029: V2 API relies on the "registerPath" attribute to decide where to register it

          Show
          jira-bot ASF subversion and git services added a comment - Commit 49b9c62dfb638b2b414a919bff9d391fe8aa2ec5 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=49b9c62 ] SOLR-8029 : V2 API relies on the "registerPath" attribute to decide where to register it
          Hide
          jira-bot ASF subversion and git services added a comment -

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

          SOLR-8029: merged changes from master

          Show
          jira-bot ASF subversion and git services added a comment - Commit d5e5da894b4a43c16b5e6d4f4d21f4a790732ca5 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=d5e5da8 ] SOLR-8029 : merged changes from master
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 943f2709a3717a840c1eaffe850904613ae9596d in lucene-solr's branch refs/heads/apiv2 from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=943f270 ]

          SOLR-8029: merged changes from master

          Show
          jira-bot ASF subversion and git services added a comment - Commit 943f2709a3717a840c1eaffe850904613ae9596d in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=943f270 ] SOLR-8029 : merged changes from master
          Hide
          jira-bot ASF subversion and git services added a comment -

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

          SOLR-8029: change dthe structure of the spec json to simplify it

          Show
          jira-bot ASF subversion and git services added a comment - Commit a9b8176fa083e6c32f8cd4bf200b92b817fc0e7e in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a9b8176 ] SOLR-8029 : change dthe structure of the spec json to simplify it
          Hide
          jira-bot ASF subversion and git services added a comment -

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

          SOLR-8029: bug fixes

          Show
          jira-bot ASF subversion and git services added a comment - Commit b1b1e97cf2e1665cd00d4e655b77216fb0415682 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b1b1e97 ] SOLR-8029 : bug fixes
          Hide
          jira-bot ASF subversion and git services added a comment -

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

          SOLR-8029: FIxed failing tests and added a testcase

          Show
          jira-bot ASF subversion and git services added a comment - Commit bbb81e0bb6881b8233a99650afe59a270334b9fc in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=bbb81e0 ] SOLR-8029 : FIxed failing tests and added a testcase
          Hide
          jira-bot ASF subversion and git services added a comment -

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

          SOLR-8029: Add V2 paths for security permissions and refactored and documented security APIs

          Show
          jira-bot ASF subversion and git services added a comment - Commit e802a4d61ed26ce43fc5bdffa3ab5391c9724dc6 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e802a4d ] SOLR-8029 : Add V2 paths for security permissions and refactored and documented security APIs
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 6c768cebca2f2ca6baa3aa7546d63ad4fc6fe37f in lucene-solr's branch refs/heads/apiv2 from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=6c768ce ]

          SOLR-8029: test should randomly run on v2

          Show
          jira-bot ASF subversion and git services added a comment - Commit 6c768cebca2f2ca6baa3aa7546d63ad4fc6fe37f in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=6c768ce ] SOLR-8029 : test should randomly run on v2
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 7209e04d4dc41f2886a7d73620648c0c63bc41ea in lucene-solr's branch refs/heads/apiv2 from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7209e04 ]

          SOLR-8029: do not keep the spec objects in memory. Load them on demand

          Show
          jira-bot ASF subversion and git services added a comment - Commit 7209e04d4dc41f2886a7d73620648c0c63bc41ea in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7209e04 ] SOLR-8029 : do not keep the spec objects in memory. Load them on demand
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 4541cc562cbf2a84625dc2d4e33e52308147d265 in lucene-solr's branch refs/heads/apiv2 from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4541cc5 ]

          SOLR-8029: Merge remote-tracking branch 'remotes/origin/master' into apiv2

          Show
          jira-bot ASF subversion and git services added a comment - Commit 4541cc562cbf2a84625dc2d4e33e52308147d265 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4541cc5 ] SOLR-8029 : Merge remote-tracking branch 'remotes/origin/master' into apiv2
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 8163ffd08318da1c525b9377339f93da4950fbf4 in lucene-solr's branch refs/heads/apiv2 from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=8163ffd ]

          SOLR-8029: Merge remote-tracking branch 'remotes/origin/master' into apiv2

          Show
          jira-bot ASF subversion and git services added a comment - Commit 8163ffd08318da1c525b9377339f93da4950fbf4 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=8163ffd ] SOLR-8029 : Merge remote-tracking branch 'remotes/origin/master' into apiv2
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 0412be5d6a469c38b5aa824cda6aea2014a2732a in lucene-solr's branch refs/heads/apiv2 from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=0412be5 ]

          SOLR-8029: More specs

          Show
          jira-bot ASF subversion and git services added a comment - Commit 0412be5d6a469c38b5aa824cda6aea2014a2732a in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=0412be5 ] SOLR-8029 : More specs
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 6aedeb9c44f7725addfefb7eb4dfa4484e826a05 in lucene-solr's branch refs/heads/apiv2 from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=6aedeb9 ]

          SOLR-8029: security api spec should be lazily loaded because it can change with the implementation

          Show
          jira-bot ASF subversion and git services added a comment - Commit 6aedeb9c44f7725addfefb7eb4dfa4484e826a05 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=6aedeb9 ] SOLR-8029 : security api spec should be lazily loaded because it can change with the implementation
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 8a5e76f4c93111265d1d0b648491091a3572ad85 in lucene-solr's branch refs/heads/apiv2 from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=8a5e76f ]

          SOLR-8029: more api spec

          Show
          jira-bot ASF subversion and git services added a comment - Commit 8a5e76f4c93111265d1d0b648491091a3572ad85 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=8a5e76f ] SOLR-8029 : more api spec
          Hide
          jira-bot ASF subversion and git services added a comment -

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

          SOLR-8029: more api spec

          Show
          jira-bot ASF subversion and git services added a comment - Commit ba3199cf6ede2c68add28dd4609caea4d180b87f in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ba3199c ] SOLR-8029 : more api spec
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 376c4e8539377647f8bbccd716fd72720c8d5af8 in lucene-solr's branch refs/heads/apiv2 from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=376c4e8 ]

          SOLR-8029: more api spec

          Show
          jira-bot ASF subversion and git services added a comment - Commit 376c4e8539377647f8bbccd716fd72720c8d5af8 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=376c4e8 ] SOLR-8029 : more api spec
          Hide
          jira-bot ASF subversion and git services added a comment -

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

          SOLR-8029: SchemaValidation

          Show
          jira-bot ASF subversion and git services added a comment - Commit c7f58b8205df8bcf21d2b7c83b77e3a324dca97d in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c7f58b8 ] SOLR-8029 : SchemaValidation
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 38d542226cbbdda1d0b7b48323f3c235a300e92f in lucene-solr's branch refs/heads/apiv2 from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=38d5422 ]

          SOLR-8029: Validate Json spec

          Show
          jira-bot ASF subversion and git services added a comment - Commit 38d542226cbbdda1d0b7b48323f3c235a300e92f in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=38d5422 ] SOLR-8029 : Validate Json spec
          Hide
          jira-bot ASF subversion and git services added a comment -

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

          SOLR-8029: enable schema enforcement for commands

          Show
          jira-bot ASF subversion and git services added a comment - Commit ba5dc7503e9e86ae636ef5f9d9e2852c4ddeb619 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ba5dc75 ] SOLR-8029 : enable schema enforcement for commands
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 31126e888a319742a153196ef3547c25b966524f in lucene-solr's branch refs/heads/apiv2 from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=31126e8 ]

          SOLR-8029: error output should be in json. spec for create command fixed

          Show
          jira-bot ASF subversion and git services added a comment - Commit 31126e888a319742a153196ef3547c25b966524f in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=31126e8 ] SOLR-8029 : error output should be in json. spec for create command fixed
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 283c648374a71026d5213ee83112cf903754b526 in lucene-solr's branch refs/heads/apiv2 from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=283c648 ]

          SOLR-8029: fixing test errors

          Show
          jira-bot ASF subversion and git services added a comment - Commit 283c648374a71026d5213ee83112cf903754b526 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=283c648 ] SOLR-8029 : fixing test errors
          Hide
          jira-bot ASF subversion and git services added a comment -

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

          SOLR-8029: mor testcases for collection api

          Show
          jira-bot ASF subversion and git services added a comment - Commit f1155e1c02e07a427dedb1f453b3d37f834c661b in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f1155e1 ] SOLR-8029 : mor testcases for collection api
          Hide
          jira-bot ASF subversion and git services added a comment -

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

          SOLR-8029 : More API spec

          Show
          jira-bot ASF subversion and git services added a comment - Commit c72aeac59e4f736e250ec7f4a5faad5903866394 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c72aeac ] SOLR-8029 : More API spec
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 7c8d3e054ece4c046e350226a3d22ebe214dd0d1 in lucene-solr's branch refs/heads/apiv2 from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7c8d3e0 ]

          SOLR-8029: Added tests for add, delete replica props

          Show
          jira-bot ASF subversion and git services added a comment - Commit 7c8d3e054ece4c046e350226a3d22ebe214dd0d1 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7c8d3e0 ] SOLR-8029 : Added tests for add, delete replica props
          Hide
          jira-bot ASF subversion and git services added a comment -

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

          SOLR-8029: more tests

          Show
          jira-bot ASF subversion and git services added a comment - Commit d9677c43403ac0c780af595d28eb811b4e277d95 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=d9677c4 ] SOLR-8029 : more tests
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 59421d9d9b98e3e8a066e30fd01481ee2ea9c8d1 in lucene-solr's branch refs/heads/apiv2 from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=59421d9 ]

          SOLR-8029: coreadmin tests and spec

          Show
          jira-bot ASF subversion and git services added a comment - Commit 59421d9d9b98e3e8a066e30fd01481ee2ea9c8d1 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=59421d9 ] SOLR-8029 : coreadmin tests and spec
          Hide
          jira-bot ASF subversion and git services added a comment -

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

          SOLR-8029: coreadmin tests and spec

          Show
          jira-bot ASF subversion and git services added a comment - Commit db32de3a83f31f509e6aa249d6e8371a46872e93 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=db32de3 ] SOLR-8029 : coreadmin tests and spec
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 4a1f9c86df0b9d68d46eca2ea111c8c76b1ca0e5 in lucene-solr's branch refs/heads/apiv2 from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4a1f9c8 ]

          SOLR-8029: precommit errors

          Show
          jira-bot ASF subversion and git services added a comment - Commit 4a1f9c86df0b9d68d46eca2ea111c8c76b1ca0e5 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4a1f9c8 ] SOLR-8029 : precommit errors
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 52aa4478de9d1ef352c28b4beccf5c442170d46b in lucene-solr's branch refs/heads/apiv2 from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=52aa447 ]

          SOLR-8029: missing mappings for /v2/cluster path

          Show
          jira-bot ASF subversion and git services added a comment - Commit 52aa4478de9d1ef352c28b4beccf5c442170d46b in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=52aa447 ] SOLR-8029 : missing mappings for /v2/cluster path
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 474141ea4342636080a9c34b76badcb0db542757 in lucene-solr's branch refs/heads/apiv2 from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=474141e ]

          SOLR-8029: give sub path info at _introspect

          Show
          jira-bot ASF subversion and git services added a comment - Commit 474141ea4342636080a9c34b76badcb0db542757 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=474141e ] SOLR-8029 : give sub path info at _introspect
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 9b8511cde4afdba1f247ae428e515420a843f7f7 in lucene-solr's branch refs/heads/apiv2 from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9b8511c ]

          SOLR-8029: /get spec was not mapped right

          Show
          jira-bot ASF subversion and git services added a comment - Commit 9b8511cde4afdba1f247ae428e515420a843f7f7 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9b8511c ] SOLR-8029 : /get spec was not mapped right
          Hide
          ctargett Cassandra Targett added a comment -

          I've started doing a functional review of this, with a build from the apiv2 branch Noble has been pushing to. I know I'll find more stuff, but as a first pass I noticed a few things to start:

          • Schema endpoints don't seem to include GET methods for fields, copyfields or dynamic fields. I found the specs for them in core/src/resources/apispec (core.SchemaRead.fields.json, core.SchemaRead.copyFields.json), but I can't get to the endpoints referred to in those spec files and they are not listed from an introspect request to the schema endpoint (i.e., http://localhost:8983/solr/v2/collections/apitest/schema/_introspect).
          • I feel like there are similar GET endpoints missing from the config endpoint, but I'll do some further analysis on that to be able to list them.
          • Replacements for the Blob Store API and the ConfigSets API are not included?
          Show
          ctargett Cassandra Targett added a comment - I've started doing a functional review of this, with a build from the apiv2 branch Noble has been pushing to. I know I'll find more stuff, but as a first pass I noticed a few things to start: Schema endpoints don't seem to include GET methods for fields, copyfields or dynamic fields. I found the specs for them in core/src/resources/apispec ( core.SchemaRead.fields.json , core.SchemaRead.copyFields.json ), but I can't get to the endpoints referred to in those spec files and they are not listed from an introspect request to the schema endpoint (i.e., http://localhost:8983/solr/v2/collections/apitest/schema/_introspect ). I feel like there are similar GET endpoints missing from the config endpoint, but I'll do some further analysis on that to be able to list them. Replacements for the Blob Store API and the ConfigSets API are not included?
          Hide
          noble.paul Noble Paul added a comment - - edited

          Thanks Cassandra

          Schema endpoints don't seem to include GET methods for fields, copyfields or dynamic fields.

          Right , those specs are not included in the output. Will add them

          Replacements for the Blob Store API and the ConfigSets API are not included?

          Not yet, I'm planning to add them to the v2 path as is.
          I need to write the spec for them

          Show
          noble.paul Noble Paul added a comment - - edited Thanks Cassandra Schema endpoints don't seem to include GET methods for fields, copyfields or dynamic fields. Right , those specs are not included in the output. Will add them Replacements for the Blob Store API and the ConfigSets API are not included? Not yet, I'm planning to add them to the v2 path as is. I need to write the spec for them
          Hide
          jira-bot ASF subversion and git services added a comment -

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

          SOLR-8029: wrong doc

          Show
          jira-bot ASF subversion and git services added a comment - Commit c07a0bfe8e47f068a00a979c5e0f09c206ced688 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c07a0bf ] SOLR-8029 : wrong doc
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 5df4ca1ebdf33508c16be9c00db622d3ec7fe2ec in lucene-solr's branch refs/heads/apiv2 from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5df4ca1 ]

          SOLR-8029: Added the missing paths in schema

          Show
          jira-bot ASF subversion and git services added a comment - Commit 5df4ca1ebdf33508c16be9c00db622d3ec7fe2ec in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5df4ca1 ] SOLR-8029 : Added the missing paths in schema
          Hide
          jira-bot ASF subversion and git services added a comment -

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

          SOLR-8029: Added configset and blob store APIs to /v2 path

          Show
          jira-bot ASF subversion and git services added a comment - Commit f72c6914a83f6cf5b287c53beb40c52244ba5a9b in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f72c691 ] SOLR-8029 : Added configset and blob store APIs to /v2 path
          Hide
          jira-bot ASF subversion and git services added a comment -

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

          SOLR-8029: merging with trunk

          Show
          jira-bot ASF subversion and git services added a comment - Commit b333e6bd0a3b86f85d68d47b65b12ef99ab03a86 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b333e6b ] SOLR-8029 : merging with trunk
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 552ad6e906f8ef63b378909d9689a20955d3e1fd in lucene-solr's branch refs/heads/apiv2 from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=552ad6e ]

          SOLR-8029: Addressing test failures

          Show
          jira-bot ASF subversion and git services added a comment - Commit 552ad6e906f8ef63b378909d9689a20955d3e1fd in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=552ad6e ] SOLR-8029 : Addressing test failures
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 22f1be69f9de124d15b9831e69d3ef1797160828 in lucene-solr's branch refs/heads/apiv2 from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=22f1be6 ]

          SOLR-8029: Addressing test failures

          Show
          jira-bot ASF subversion and git services added a comment - Commit 22f1be69f9de124d15b9831e69d3ef1797160828 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=22f1be6 ] SOLR-8029 : Addressing test failures
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 49a09217064d6f1578895cf8425946bb2d08338d in lucene-solr's branch refs/heads/apiv2 from Steve Rowe
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=49a0921 ]

          SOLR-8029: merge master into apiv2

          Show
          jira-bot ASF subversion and git services added a comment - Commit 49a09217064d6f1578895cf8425946bb2d08338d in lucene-solr's branch refs/heads/apiv2 from Steve Rowe [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=49a0921 ] SOLR-8029 : merge master into apiv2
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit f9f148fb7cf602ddefb25c6edd33887c6a93bcf0 in lucene-solr's branch refs/heads/apiv2 from Steve Rowe
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f9f148f ]

          SOLR-8029: make precommit happy: drop unused imports and move license headers to the top of files

          Show
          jira-bot ASF subversion and git services added a comment - Commit f9f148fb7cf602ddefb25c6edd33887c6a93bcf0 in lucene-solr's branch refs/heads/apiv2 from Steve Rowe [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f9f148f ] SOLR-8029 : make precommit happy: drop unused imports and move license headers to the top of files
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 003f9b74a55d73473d8f58670f09c5abd4253c96 in lucene-solr's branch refs/heads/apiv2 from Steve Rowe
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=003f9b7 ]

          SOLR-8029: API spec resource names: s/commands/Commands/

          Show
          jira-bot ASF subversion and git services added a comment - Commit 003f9b74a55d73473d8f58670f09c5abd4253c96 in lucene-solr's branch refs/heads/apiv2 from Steve Rowe [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=003f9b7 ] SOLR-8029 : API spec resource names: s/commands/Commands/
          Hide
          arafalov Alexandre Rafalovitch added a comment -

          I am reading the spec as a newbie, so these are comments in light of that:

          Solr Resources description

          • core ? - we should mention/explain core not just mention it
          • configset - Zookeeper only? What about for non SolrCloud installations
          • Non-distributed collection terminology - Is it still collection or core? Or both

          Conventions

          • What's SMILE? Takes a while to find reference to some binary JSON, but the fasterxml website was (is?) dead, maybe cross-reference JIRA we implemented it
          • Query endpoints return a lot more formats (CSV, PHP, Python, HTML from /browse). Are those not discussed somehow?
          • HJSON or HOCON (misspelling or two different things?)
          • Endpoints that require input payloads - does this include "update" endpoint? What about XML Update format? What about /extract end point, is it update? Maybe clarify this a bit.
          • What's an example of an operation key? Forward reference I guess, but hard to visualize this early in the document
          • Operations are specified using snake case using either a dash or underscore - Who is making this choice? Are some operations defined one way and others the other? Or the client call can use either? This is super-confusing and can cause issues to the client applications. Why can't we just have one way on this, since everything has to be redone anyway.
          • /v2/admin was already discussed for static resources, the spec should be updated if that's accepted as the solution

          API Versioning

          • Still talks about /solr/v2

          Introspection support

          • Is Schema auto-generated from something or manually written?
          • If it is auto-generated, what is the self-description mechanism used for that. Because it would be good to have pluggable components (e.g. URPs, analysers) to self-describe themselves too, it is not clear whether that would be the same effort umbrella or a separate one.

          List collections

          • Does the name parameter support the full Java regex or just star? If just star, there is no point being 'flexible' about. But if it is full regex (e.g. test[a-z][0-9]) , it is worth mentioning.
          • config param - return all collections that use the specific ?collection? (configset I am guessing, maybe call it configset too)

          Create collection

          • configTemplate? - is that same as configset? If not, need to explain.
          • With async, why are we making request to one endpoint but getting its status from another. That could mess a lot of users/tools up. Can we not proxy it internally or something. (documentation later for delete command seem to imply that this is already what is planned)
          • Is there no useful information to be returned when collection is created? Like which nodes it ends up on?

          Collection configuration

          • sharedConfigName vs configTemplate vs - unmentioned - configset - this really needs to be explained in the resource description section
          • Again, what happens without SolrCloud here? We are still supporting it or is the assumption we will not. If we will not, this needs to be documented as explicit precondition before merging this into master (e.g. definitely not version 6)

          Collection Alias

          • Endpoint (/v2/...) is completely mismatching to the example. One of them is very out of date
          • Earlier we said that alias is opaque to the user, which I read to say that call to list the collections would return aliases as well (good for tools). Now, it seems that they are returned in a collection_aliases end point. Is that instead or in addition? Think about Admin UI, would we want an alias in the dropdown of options to run a query against (I would think yes)?
          • No output seems to be shown, but will there be a marker that something is an alias? Or a list of collections that alias creates?
          • It would make sense to have a filter that lists all aliases a collection a part of (it can be present in multiple I believe)

          Collection API and Collection Exists

          • needs to be updated to use /v2/collections/collectionName structure

          Collection Delete

          • What happens if we provide an alias name here?

          Swap collections?

          • Do we support swapping the collections? In non-Cloud mode, obviously. And if we only have Cloud mode, how do we support those use-cases?

          Collection Administration Tasks

          • Examples are all-over the place in terms of URL structure.

          Link Config

          • That's linking to which one of the sharedConfigName, configTemplate or configset?
          • Can reload fail? If so, would having and not having reload=true cause different versions of output to be present? Are there other operations that also need reload afterwards? This should be consistent.

          Share Configs

          • This dual-API is super-significant for tools and Admin UI. How exactly would they know which API to use for a specific collection? What about when the name given is an alias? The return format of calls that will allow this decision should be really clearly documented
          • Update collection
          • Very confusing section. Is this taking into account swapped default and solr-format JSON end-points? What about Solr XML Update format? Extract?

          (I stopped here for now)

          Show
          arafalov Alexandre Rafalovitch added a comment - I am reading the spec as a newbie, so these are comments in light of that: Solr Resources description core ? - we should mention/explain core not just mention it configset - Zookeeper only? What about for non SolrCloud installations Non-distributed collection terminology - Is it still collection or core? Or both Conventions What's SMILE? Takes a while to find reference to some binary JSON, but the fasterxml website was (is?) dead, maybe cross-reference JIRA we implemented it Query endpoints return a lot more formats (CSV, PHP, Python, HTML from /browse). Are those not discussed somehow? HJSON or HOCON (misspelling or two different things?) Endpoints that require input payloads - does this include "update" endpoint? What about XML Update format? What about /extract end point, is it update? Maybe clarify this a bit. What's an example of an operation key ? Forward reference I guess, but hard to visualize this early in the document Operations are specified using snake case using either a dash or underscore - Who is making this choice? Are some operations defined one way and others the other? Or the client call can use either? This is super-confusing and can cause issues to the client applications. Why can't we just have one way on this, since everything has to be redone anyway. /v2/admin was already discussed for static resources, the spec should be updated if that's accepted as the solution API Versioning Still talks about /solr/v2 Introspection support Is Schema auto-generated from something or manually written? If it is auto-generated, what is the self-description mechanism used for that. Because it would be good to have pluggable components (e.g. URPs, analysers) to self-describe themselves too, it is not clear whether that would be the same effort umbrella or a separate one. List collections Does the name parameter support the full Java regex or just star? If just star, there is no point being 'flexible' about. But if it is full regex (e.g. test[a-z] [0-9] ) , it is worth mentioning. config param - return all collections that use the specific ?collection? (configset I am guessing, maybe call it configset too) Create collection configTemplate ? - is that same as configset? If not, need to explain. With async, why are we making request to one endpoint but getting its status from another. That could mess a lot of users/tools up. Can we not proxy it internally or something. (documentation later for delete command seem to imply that this is already what is planned) Is there no useful information to be returned when collection is created? Like which nodes it ends up on? Collection configuration sharedConfigName vs configTemplate vs - unmentioned - configset - this really needs to be explained in the resource description section Again, what happens without SolrCloud here? We are still supporting it or is the assumption we will not. If we will not, this needs to be documented as explicit precondition before merging this into master (e.g. definitely not version 6) Collection Alias Endpoint (/v2/...) is completely mismatching to the example. One of them is very out of date Earlier we said that alias is opaque to the user, which I read to say that call to list the collections would return aliases as well (good for tools). Now, it seems that they are returned in a collection_aliases end point. Is that instead or in addition? Think about Admin UI, would we want an alias in the dropdown of options to run a query against (I would think yes)? No output seems to be shown, but will there be a marker that something is an alias? Or a list of collections that alias creates? It would make sense to have a filter that lists all aliases a collection a part of (it can be present in multiple I believe) Collection API and Collection Exists needs to be updated to use /v2/collections/collectionName structure Collection Delete What happens if we provide an alias name here? Swap collections? Do we support swapping the collections? In non-Cloud mode, obviously. And if we only have Cloud mode, how do we support those use-cases? Collection Administration Tasks Examples are all-over the place in terms of URL structure. Link Config That's linking to which one of the sharedConfigName , configTemplate or configset ? Can reload fail? If so, would having and not having reload=true cause different versions of output to be present? Are there other operations that also need reload afterwards? This should be consistent. Share Configs This dual-API is super-significant for tools and Admin UI. How exactly would they know which API to use for a specific collection? What about when the name given is an alias? The return format of calls that will allow this decision should be really clearly documented Update collection Very confusing section. Is this taking into account swapped default and solr-format JSON end-points? What about Solr XML Update format? Extract? (I stopped here for now)
          Hide
          steve_rowe Steve Rowe added a comment -

          I reviewed the changes on the apiv2 branch, and found many small problems, which I've listed below. I didn't attempt to prioritize them - I think they all should be addressed.

          Miscellaneous

          1. I couldn't find any V2 version of these old collections api actions: CLUSTERPROP, BALANCESHARDUNIQUE, MIGRATESTATEFORMAT, BACKUP, RESTORE, ADDROLE, REMOVEROLE
          2. Some plugins, e.g. /replication, don't have _introspect support - is this intentional?
          3. Question: I can't find it now, but I saw somewhere that only one command is allowed when POSTing to V2 APIs.
            • Is this true?
            • What about bulk schema and config APIs? Manual V2 schema api testing with multiple commands in a single request resulted in all but the first command being silently ignored.

          API spec files

          1. There are many many many missing descriptions & documentation links, and many top-level CWIKI documentation links
            • I think it's very important to make these as complete as possible
          2. Default value documentation is missing almost everywhere
            • I think these should be filled in where possible
          3. /url/path appears to be an orphan in many *.json files - I can't find any use of it in code, and when it appears in *.json files, it's always a subset of /url/paths (plural).
          4. These orphaned spec files should be removed:
            • cores.core.Commands.requestRecovery.json (directly specified in cores.core.Commands.json)
            • cores.json (handled by cores.Status.json)
          5. Empty command properties maps, should be removed from:
            • cluster.security.BasicAuth.Commands.json: /commands/set-user
            • cluster.security.RuleBasedAuthorization.json: /commands/set-permission/params
          6. cluster.config.Commands.json:
            • "delete" command should be removed, since that functionality is covered by cluster.config.delete.json
          7. cluster.security.RuleBasedAuthorization.json:
            • /commands/delete-permission:
              • "type" key is present twice - "type":"object" should be removed (since it should be "int")
            • /commands/set-user-role:
              • description should state that multiple roles should be comma-separated.
          8. cluster.security.authentication.Commands.json
            • Why does it contain no commands?
          9. cluster.security.authorization.Commands.json
            • Why does it contain no commands?
          10. cluster.security.RuleBasedAuthorization.json:
            • "set-permission" and "update-permission" commands: required "role" property is never defined.
            • "set-permission" command: "method" should be restricted to the allowed values (GET, POST, etc.)
              • JsonSchemaValidator will have to be modified to support the "enum" JSON schema feature
            • "update-permission" command: "index" property is required, but shouldn't be, since "before" could be specified instead.
          11. collections.Commands.json:
            • description is spelled "Description" (capital "D") but should be lowercase
            • description is a copy-paste-o:"The add-field command adds a new field definition to your schema."
          12. core.config.Commands.json:
            • type is object, no validation on the object?: most commands have this problem
              • e.g.: add-requesthandler should have required "name" and "class" (as should all update-* and add-* commands?)
          13. core.RealtimeGet.json:
            • Missing "fq" param
            • How do /get/update and /get/versions work, and what do they do? I don't see any code to handle them.
            • /v2/c/{collection}/_introspect doesn't return /get/... in availableSubPaths, but it should
              • same problem for cores
            • /v2/c/{collection}/get/_introspect says that the paths are /get/..., but that's wrong: they're /v2/c/{collection}/get/...
              • same problem for cores
          14. core.SchemaEdit.json:
            • Non-supported properties that should be removed: "tokenized", "binary"
            • Bulk mode doesn't work - any command after the first appears to be silently ignored
              • Why isn't testing failing?
            • /v2/c/{collection}/_introspect doesn't return /schema/... in availableSubPaths, but it should
              • same problem for cores
            • /v2/c/{collection}/schema/_introspect says that the paths are /schema/..., but that's wrong: they're /v2/c/{collection}/schema/...
              • same problem for cores
          15. core.SchemaRead.fields.json:
            • includeDynamic only applies to /schema/fields, but /schema/dynamicfields and /schema/fieldtypes are included in /url/paths
          16. cluster.json
            • /v2/cluster/nodes endpoint returns same results as /v2/cluster - is /v2/cluster/nodes supposed to do something different? If not, why does it need to be here?
          17. cluster.commandstatus.json
            • There is no way to delete a command status (old collections api: DELETESTATUS action) - you can only get info on one via: GET /v2/cluster/command-status/{id}.
            • Maybe this endpoint could renamed from /v2/cluster/command-status to /v2/cluster/async-command, and then have DELETE available on /v2/cluster/async-command/{id}?
          18. cluster.config.*.json
            • should be renamed to "cluster.configs.*.json" (plural) - the endpoint is /cluster/configs (plural)
          19. collection.json
            • should be renamed to collections.collection.json
            • CollectionHandlerApi.EndPoint.COLLECTION_STATE will need to have its spec name updated
          20. collections.collection.Commands.json
            • Missing command: migrate-docs
          21. collections.collection.Commands.modify.json:
            • "maxShardsPerNode" property is missing
          22. collections.collection.shards.Commands.json
            • "async" key is missing for "split", "create" and "add-replica" commands
            • "create" command: "createNodeSet" description should say it's a comma-separated list
            • "add-replica" command: "shard" property description is incomplete: "The name of the shard where "
          23. collections.collection.shards.shard.Commands.json:
            • force-leader <- additionalProperties should be false instead of true, since none are supported
            • Missing command: "synch-shard" <- I think this should be spelled "sync-shard"
          24. collections.collection.shards.shard.replica.Commands.json
            • "set-property" command should take an array
            • /commands/set-property/properties/value/description is wrong (copy-paste-o): "The property name"
          25. collections.collection.shards.shard.replica.delete.json
            • "async" param is missing
          26. collections.Commands.json
            • "async" key is missing for "create", "create-alias" and "delete-alias" commands.
            • /commands/create:
              • "createNodeSet.shuffle" key is missing
              • "maxShardsPerNode" key is missing
          27. core.config.Params.Commands.json
            • /commands/update/description: "update one or more configsets", <- should be parameter sets
          28. core.SchemaEdit.addFieldType.json:
            • "queryAnalyzer" and "indexAnalyzer" should be added as possible keys
            • analyzer objects ("analyzer" and the above two) should not include the "type" key
            • analyzer objects should include "class", "charFilters", "tokenizer" and "filters" keys, each with appropriate sub-config.
          29. core.SchemaEdit.replaceFieldType.json
            • should be the same schema as core.SchemaEdit.addFieldType, but is currently almost empty.
          30. core.SchemaRead.json:
            • "/schema/similarity" is present 3 times
            • "/schema/zkversion" and "/schema/uniquekey" are present 2 times
            • Maybe there should be a test for the multiply-specified-path problem (e.g. in JsonSchemaValidator)?
          31. core.SchemaRead.fields.json
            • params only apply to the "fields" endpoint, so why are dynamicfields and fieldtypes included here?
          32. core.Update.json
            • /update/json/commands <- is this path new? seems to be rewritten/forwarded to /update/json in UpdateRequestHandlerApi. Is adding this endpoint necessary?
            • Missing path: /update/json/docs
            • (maybe?) missing path: /update/bin
          33. cores.Commands.json:
            • The description on "schema" and "dataDir" are copy/paste-o's ("The core name")
            • "numShards" description starts "NO:of", which may not be understood by some, should be "number of" instead.
            • /commands/create:
              • "async" key is missing
              • "configset" should not be required - it's not included in CoreDescriptor.requiredProperties
                • or if I'm wrong and it is required, then it's misspelled ("configSet" is the correct spelling)
          34. cores.core.Commands.json
            • missing command: "request-status" (corresponding to REQUESTSTATUS)
            • missing command: "pre-recovery" (corresponding to PRERECOVERY)
            • missing command: "request-sync-shard" (corresponding to REQUESTSYNCSHARD)
            • missing command: "request-buffer-updates" (corresponding to REQUESTBUFFERUPDATES)
            • missing command: "request-apply-updates" (corresponding to REQUESTAPPLYUPDATES)
            • "async" key is missing from "swap", "rename", "unload", "merge-indexes" commands
            • /commands/reload
              • "additionalProperties" should be false, not true
            • /commands/merge-indexes
              • Missing properties: "indexDir", "srcCore", "async"
            • /commands/request-recovery
              • "additionalProperties" should be false, not true
            • /commands/forceprepareforleadership:
              • I think it should be spelled "force-prepare-for-leadership"
              • "additionalProperties" should be false, not true
          35. cores.core.Commands.split.json
            • "path" and "targetCore" are singular but take arrays - the descriptions should be plural but are now singular.
            • "ranges" is plural but takes a single string - why is treated differently from "path" and "targetCore"?
          36. cores.Status.json
            • "indexInfo" param default is wrong: it's true, not false
            • I think core-specific status should be at /v2/cores/{core} (currently 404's), rather than at /v2/cores/{core}/status - that would be consistent with the V2 Collections API per-collection status at /v2/c/{collection}
          37. node.Commands.json
            • Missing commands: add-role, remove-role
            • /commands/overseerop
              • I think it should be spelled "overseer-op"
              • Missing properties: "op" and "electionNode"
              • "additionalProperties" should be false, not true
            • /commands/rejoinleaderelection
              • I think it should be spelled "rejoin-leader-election"
              • "additionalProperties" should be false, not true
          38. node.invoke.json:
            • Missing param: "class"

          JSON schema validation

          1. "int" is used instead of "integer" in schemas (json-schema requires "integer")
          2. JsonSchemaValidator has no "integer" support, only "number" (e.g. no INTEGER in JsonSchemaValidator.Type, ApiBag.KNOWN_TYPES)
          3. JsonSchemaValidator doesn't validate type values - using an invalid type gives an NPE instead of a useful error message
            • JsonValidatorTest is incomplete: it should test all supported schema validation aspects
            • Did you explore existing JSON validation libraries (instead of implementing from scratch)?
          4. JsonSchemaValidator
            • Class javadocs should fully describe the limitations it has compared to full JSON schema support
            • Type.valdateData() is misspelled, should be validateData()
            • Attribute.validateData is unused, should be removed
            • Attribute class name is too vague - it could be named SchemaNode instead, since it represents a node in a JSON schema graph.
            • ObjectAttribute class name is too vague - it could be named SchemaAttribute instead, since it is a set of schema object attribute validators

          Code/resources

          1. solr/core/src/resources/implicitPlugins.json
            • references "update_json_docs" as paramsets to be used by the "update" and "/update/json/docs" endpoints, but the definition for these is only in techproducts example - shouldn't a copy of it be in all example configsets? Or maybe instead in solr/core/src/resources/?
          2. Map2:
            • there are no direct tests of this class, but there should be
            • generic <K,V> should be dropped (the delegate map should probably be <String,Object> though)
              • values can be of any type
              • no generic uses in the code
            • Map2 name is too vague - maybe call it ValidatingJsonMap?
              • Differences from Java's Map:
                • value validation
                • value type coersion to JSON types
                • JSON deserialization
                • deep copy
            • NOT_NULL_OF_TYPE lambda is never used (and has a bug: first of pair's type is checked against itself instead of against second of pair's)
            • getDeepCopy(Collection,int,boolean) can be removed in favor of the exact duplicate in o.a.s.Utils
          3. o.a.s.common.util.Predicate looks very similar to Java8's Predicate, except that the instead of returning a boolean, the test() method returns either null for success or a String containing a failure explanation. I think it's bad to have a same-named class that behaves slightly differently. Maybe name it ExplanatoryPredicate?
          4. o.a.s.common.util.Lookup interface is never used, so should be removed
          5. ApiBag
            • registerLazy() doesn't use its generic type parameter <T>, so it should be removed
            • validateAndRegister(): this looks like orphaned code - there is no /url/parts in any *.json file:
                    Map2 parts = url.getMap("parts", null);
                    if (parts != null) {
                      Set<String> wildCardNames = getWildCardNames(paths);
                      for (Object o : parts.keySet()) {
                        if (!wildCardNames.contains(o.toString()))
                          throw new RuntimeException("" + o + " is not a valid part name");
                        Map2 pathMeta = parts.getMap(o.toString(), NOT_NULL);
                        pathMeta.get("type", ENUM_OF, ImmutableSet.of("enum", "string", "int", "number", "boolean"));
                      }
                    }
              
            • getWildCardNames() isn't called from anywhere but the above dead code, so can it also be removed?
            • IntrospectApi.call() makes a deep copy of the base api spec map on every request, apparently to exclude description of commands that were not called. This seems inefficient - maybe there should be a per-command cache or something?
          6. URL templates are used in various places, but names in code are inconsistent:
            • In DumpRequestHandler.handleRequestBody(), "urlPart" should be renamed, e.g. to "urlTemplateValues"/"templates" :
              String[] parts = req.getParams().getParams("urlPart");
              if (parts != null && parts.length > 0) {
                Map map = new LinkedHashMap<>();
                rsp.getValues().add("urlPart", map);
                for (String part : parts) {
                  map.put(part, req.getPathValues().get(part));
                }
              }
              
            • In PathTrie:
              • "parts" is used to mean both "url path segment sequence" and "path segment template mappings". E.g. in lookup(Map parts) <- parts is a map from path segment template name to concrete value, e.g "{collection}"->mycollection. Maybe rename the "path segment template mappings" ones to (path)(segment)templates(map)?
              • wildCardName() and Node.varName should be renamed, e.g. to (get)templateName
            • SolrQueryRequest.getPathValues() should be renamed, e.g. to getPathSegmentTemplateMappings() or getTemplates()
          7. URL path segment sequences are used in various places, but names in code are inconsistent:
            • In PathTrie and V2HttpCall, List<String> getParts()/"parts"/"pieces"/"path" usages would be more easily identifiable if referred to consistently as "segments" (since we're talking URL path segments here).
          8. TestPathTrie.testPathTrie() should clear the "parts" template map between lookup calls; otherwise previous paths' template values will linger.
          9. PathTrie:
            • findValidChildren() <- why is "valid" part of this method name? There doesn't seem to be any filtering for validity here - it's more like "recursively enumerate all descendant paths". Maybe rename to "getAvailableSubPaths" (same as "availableSubPaths" result set)?
            • Node.lookup(List,int,Map,Set) really really needs comments. It took me 10 minutes of staring to figure out this 13 line method. Specifically, the role of the "i" path segment counter should be thoroughly explained, including its relationship to the current node in the trie.
          10. ApiCommand
            • commented out code should be removed.
            • generic type param is never used, so should be removed.
          11. V2HttpCall:
            • getApiInfo(): typo: s/4044/404/ in: // this is to return the user with all the subpaths for a given 4044 request
            • execute(): //todo remove. for debugging only
          12. CollectionHandlerApi
            • prefixSubStitutes() should be prefixSubstitutes() (second "S" should be lowercase)
          13. UpdateRequestHandler
            • shouldn't /update/bin be "application/javabin" instead of "application/csv"?:
              • createDefaultLoaders():
                pathVsLoaders.put(BIN_PATH,registry.get("application/csv"));
                ...    
                public static final String BIN_PATH = "/update/bin";
                
            • Is /update/bin supported? It's not listed in core.Update.json or in ImplicitPlugins.json.
          14. ReplicationHandler
            • LOCATION is unused and should be removed.
          Show
          steve_rowe Steve Rowe added a comment - I reviewed the changes on the apiv2 branch, and found many small problems, which I've listed below. I didn't attempt to prioritize them - I think they all should be addressed. Miscellaneous I couldn't find any V2 version of these old collections api actions: CLUSTERPROP, BALANCESHARDUNIQUE, MIGRATESTATEFORMAT, BACKUP, RESTORE, ADDROLE, REMOVEROLE Some plugins, e.g. /replication, don't have _introspect support - is this intentional? Question: I can't find it now, but I saw somewhere that only one command is allowed when POSTing to V2 APIs. Is this true? What about bulk schema and config APIs? Manual V2 schema api testing with multiple commands in a single request resulted in all but the first command being silently ignored. API spec files There are many many many missing descriptions & documentation links, and many top-level CWIKI documentation links I think it's very important to make these as complete as possible Default value documentation is missing almost everywhere I think these should be filled in where possible /url/path appears to be an orphan in many *.json files - I can't find any use of it in code, and when it appears in *.json files, it's always a subset of /url/paths (plural). These orphaned spec files should be removed: cores.core.Commands.requestRecovery.json (directly specified in cores.core.Commands.json) cores.json (handled by cores.Status.json) Empty command properties maps, should be removed from: cluster.security.BasicAuth.Commands.json: /commands/set-user cluster.security.RuleBasedAuthorization.json: /commands/set-permission/params cluster.config.Commands.json: "delete" command should be removed, since that functionality is covered by cluster.config.delete.json cluster.security.RuleBasedAuthorization.json: /commands/delete-permission: "type" key is present twice - "type":"object" should be removed (since it should be "int") /commands/set-user-role: description should state that multiple roles should be comma-separated. cluster.security.authentication.Commands.json Why does it contain no commands? cluster.security.authorization.Commands.json Why does it contain no commands? cluster.security.RuleBasedAuthorization.json: "set-permission" and "update-permission" commands: required "role" property is never defined. "set-permission" command: "method" should be restricted to the allowed values (GET, POST, etc.) JsonSchemaValidator will have to be modified to support the "enum" JSON schema feature "update-permission" command: "index" property is required, but shouldn't be, since "before" could be specified instead. collections.Commands.json: description is spelled "Description" (capital "D") but should be lowercase description is a copy-paste-o:"The add-field command adds a new field definition to your schema." core.config.Commands.json: type is object, no validation on the object?: most commands have this problem e.g.: add-requesthandler should have required "name" and "class" (as should all update-* and add-* commands?) core.RealtimeGet.json: Missing "fq" param How do /get/update and /get/versions work, and what do they do? I don't see any code to handle them. /v2/c/{collection}/_introspect doesn't return /get/... in availableSubPaths, but it should same problem for cores /v2/c/{collection}/get/_introspect says that the paths are /get/..., but that's wrong: they're /v2/c/{collection}/get/... same problem for cores core.SchemaEdit.json: Non-supported properties that should be removed: "tokenized", "binary" Bulk mode doesn't work - any command after the first appears to be silently ignored Why isn't testing failing? /v2/c/{collection}/_introspect doesn't return /schema/... in availableSubPaths, but it should same problem for cores /v2/c/{collection}/schema/_introspect says that the paths are /schema/..., but that's wrong: they're /v2/c/{collection}/schema/... same problem for cores core.SchemaRead.fields.json: includeDynamic only applies to /schema/fields, but /schema/dynamicfields and /schema/fieldtypes are included in /url/paths cluster.json /v2/cluster/nodes endpoint returns same results as /v2/cluster - is /v2/cluster/nodes supposed to do something different? If not, why does it need to be here? cluster.commandstatus.json There is no way to delete a command status (old collections api: DELETESTATUS action) - you can only get info on one via: GET /v2/cluster/command-status/{id}. Maybe this endpoint could renamed from /v2/cluster/command-status to /v2/cluster/async-command, and then have DELETE available on /v2/cluster/async-command/{id}? cluster.config.*.json should be renamed to "cluster.configs.*.json" (plural) - the endpoint is /cluster/configs (plural) collection.json should be renamed to collections.collection.json CollectionHandlerApi.EndPoint.COLLECTION_STATE will need to have its spec name updated collections.collection.Commands.json Missing command: migrate-docs collections.collection.Commands.modify.json: "maxShardsPerNode" property is missing collections.collection.shards.Commands.json "async" key is missing for "split", "create" and "add-replica" commands "create" command: "createNodeSet" description should say it's a comma-separated list "add-replica" command: "shard" property description is incomplete: "The name of the shard where " collections.collection.shards.shard.Commands.json: force-leader <- additionalProperties should be false instead of true, since none are supported Missing command: "synch-shard" <- I think this should be spelled "sync-shard" collections.collection.shards.shard.replica.Commands.json "set-property" command should take an array /commands/set-property/properties/value/description is wrong (copy-paste-o): "The property name" collections.collection.shards.shard.replica.delete.json "async" param is missing collections.Commands.json "async" key is missing for "create", "create-alias" and "delete-alias" commands. /commands/create: "createNodeSet.shuffle" key is missing "maxShardsPerNode" key is missing core.config.Params.Commands.json /commands/update/description: "update one or more configsets ", <- should be parameter sets core.SchemaEdit.addFieldType.json: "queryAnalyzer" and "indexAnalyzer" should be added as possible keys analyzer objects ("analyzer" and the above two) should not include the "type" key analyzer objects should include "class", "charFilters", "tokenizer" and "filters" keys, each with appropriate sub-config. core.SchemaEdit.replaceFieldType.json should be the same schema as core.SchemaEdit.addFieldType, but is currently almost empty. core.SchemaRead.json: "/schema/similarity" is present 3 times "/schema/zkversion" and "/schema/uniquekey" are present 2 times Maybe there should be a test for the multiply-specified-path problem (e.g. in JsonSchemaValidator)? core.SchemaRead.fields.json params only apply to the "fields" endpoint, so why are dynamicfields and fieldtypes included here? core.Update.json /update/json/commands <- is this path new? seems to be rewritten/forwarded to /update/json in UpdateRequestHandlerApi. Is adding this endpoint necessary? Missing path: /update/json/docs (maybe?) missing path: /update/bin cores.Commands.json: The description on "schema" and "dataDir" are copy/paste-o's ("The core name") "numShards" description starts "NO:of", which may not be understood by some, should be "number of" instead. /commands/create: "async" key is missing "configset" should not be required - it's not included in CoreDescriptor.requiredProperties or if I'm wrong and it is required, then it's misspelled ("configSet" is the correct spelling) cores.core.Commands.json missing command: "request-status" (corresponding to REQUESTSTATUS) missing command: "pre-recovery" (corresponding to PRERECOVERY) missing command: "request-sync-shard" (corresponding to REQUESTSYNCSHARD) missing command: "request-buffer-updates" (corresponding to REQUESTBUFFERUPDATES) missing command: "request-apply-updates" (corresponding to REQUESTAPPLYUPDATES) "async" key is missing from "swap", "rename", "unload", "merge-indexes" commands /commands/reload "additionalProperties" should be false, not true /commands/merge-indexes Missing properties: "indexDir", "srcCore", "async" /commands/request-recovery "additionalProperties" should be false, not true /commands/forceprepareforleadership: I think it should be spelled "force-prepare-for-leadership" "additionalProperties" should be false, not true cores.core.Commands.split.json "path" and "targetCore" are singular but take arrays - the descriptions should be plural but are now singular. "ranges" is plural but takes a single string - why is treated differently from "path" and "targetCore"? cores.Status.json "indexInfo" param default is wrong: it's true, not false I think core-specific status should be at /v2/cores/{core} (currently 404's), rather than at /v2/cores/{core}/status - that would be consistent with the V2 Collections API per-collection status at /v2/c/{collection} node.Commands.json Missing commands: add-role, remove-role /commands/overseerop I think it should be spelled "overseer-op" Missing properties: "op" and "electionNode" "additionalProperties" should be false, not true /commands/rejoinleaderelection I think it should be spelled "rejoin-leader-election" "additionalProperties" should be false, not true node.invoke.json: Missing param: "class" JSON schema validation "int" is used instead of "integer" in schemas (json-schema requires "integer") JsonSchemaValidator has no "integer" support, only "number" (e.g. no INTEGER in JsonSchemaValidator.Type, ApiBag.KNOWN_TYPES) JsonSchemaValidator doesn't validate type values - using an invalid type gives an NPE instead of a useful error message JsonValidatorTest is incomplete: it should test all supported schema validation aspects Did you explore existing JSON validation libraries (instead of implementing from scratch)? JsonSchemaValidator Class javadocs should fully describe the limitations it has compared to full JSON schema support Type.valdateData() is misspelled, should be validateData() Attribute.validateData is unused, should be removed Attribute class name is too vague - it could be named SchemaNode instead, since it represents a node in a JSON schema graph. ObjectAttribute class name is too vague - it could be named SchemaAttribute instead, since it is a set of schema object attribute validators Code/resources solr/core/src/resources/implicitPlugins.json references "update_json_docs" as paramsets to be used by the "update" and "/update/json/docs" endpoints, but the definition for these is only in techproducts example - shouldn't a copy of it be in all example configsets? Or maybe instead in solr/core/src/resources/? Map2: there are no direct tests of this class, but there should be generic <K,V> should be dropped (the delegate map should probably be <String,Object> though) values can be of any type no generic uses in the code Map2 name is too vague - maybe call it ValidatingJsonMap? Differences from Java's Map: value validation value type coersion to JSON types JSON deserialization deep copy NOT_NULL_OF_TYPE lambda is never used (and has a bug: first of pair's type is checked against itself instead of against second of pair's) getDeepCopy(Collection,int,boolean) can be removed in favor of the exact duplicate in o.a.s.Utils o.a.s.common.util.Predicate looks very similar to Java8's Predicate, except that the instead of returning a boolean, the test() method returns either null for success or a String containing a failure explanation. I think it's bad to have a same-named class that behaves slightly differently. Maybe name it ExplanatoryPredicate? o.a.s.common.util.Lookup interface is never used, so should be removed ApiBag registerLazy() doesn't use its generic type parameter <T>, so it should be removed validateAndRegister(): this looks like orphaned code - there is no /url/parts in any *.json file: Map2 parts = url.getMap( "parts" , null ); if (parts != null ) { Set< String > wildCardNames = getWildCardNames(paths); for ( Object o : parts.keySet()) { if (!wildCardNames.contains(o.toString())) throw new RuntimeException( "" + o + " is not a valid part name"); Map2 pathMeta = parts.getMap(o.toString(), NOT_NULL); pathMeta.get( "type" , ENUM_OF, ImmutableSet.of( " enum " , "string" , " int " , "number" , " boolean " )); } } getWildCardNames() isn't called from anywhere but the above dead code, so can it also be removed? IntrospectApi.call() makes a deep copy of the base api spec map on every request, apparently to exclude description of commands that were not called. This seems inefficient - maybe there should be a per-command cache or something? URL templates are used in various places, but names in code are inconsistent: In DumpRequestHandler.handleRequestBody(), "urlPart" should be renamed, e.g. to "urlTemplateValues"/"templates" : String [] parts = req.getParams().getParams( "urlPart" ); if (parts != null && parts.length > 0) { Map map = new LinkedHashMap<>(); rsp.getValues().add( "urlPart" , map); for ( String part : parts) { map.put(part, req.getPathValues().get(part)); } } In PathTrie: "parts" is used to mean both "url path segment sequence" and "path segment template mappings". E.g. in lookup(Map parts) <- parts is a map from path segment template name to concrete value, e.g "{collection}"->mycollection. Maybe rename the "path segment template mappings" ones to (path)(segment)templates(map)? wildCardName() and Node.varName should be renamed, e.g. to (get)templateName SolrQueryRequest.getPathValues() should be renamed, e.g. to getPathSegmentTemplateMappings() or getTemplates() URL path segment sequences are used in various places, but names in code are inconsistent: In PathTrie and V2HttpCall, List<String> getParts()/"parts"/"pieces"/"path" usages would be more easily identifiable if referred to consistently as "segments" (since we're talking URL path segments here). TestPathTrie.testPathTrie() should clear the "parts" template map between lookup calls; otherwise previous paths' template values will linger. PathTrie: findValidChildren() <- why is "valid" part of this method name? There doesn't seem to be any filtering for validity here - it's more like "recursively enumerate all descendant paths". Maybe rename to "getAvailableSubPaths" (same as "availableSubPaths" result set)? Node.lookup(List,int,Map,Set) really really needs comments. It took me 10 minutes of staring to figure out this 13 line method. Specifically, the role of the "i" path segment counter should be thoroughly explained, including its relationship to the current node in the trie. ApiCommand commented out code should be removed. generic type param is never used, so should be removed. V2HttpCall: getApiInfo(): typo: s/4044/404/ in: // this is to return the user with all the subpaths for a given 4044 request execute(): //todo remove. for debugging only CollectionHandlerApi prefixSubStitutes() should be prefixSubstitutes() (second "S" should be lowercase) UpdateRequestHandler shouldn't /update/bin be "application/javabin" instead of "application/csv"?: createDefaultLoaders(): pathVsLoaders.put(BIN_PATH,registry.get( "application/csv" )); ... public static final String BIN_PATH = "/update/bin" ; Is /update/bin supported? It's not listed in core.Update.json or in ImplicitPlugins.json. ReplicationHandler LOCATION is unused and should be removed.
          Hide
          noble.paul Noble Paul added a comment -

          Thanks Alexandre Rafalovitch A lot of stuff that is there is the spec is not implemented . The scope is vast. I strongly recommend you to take a look at the branch v2api

          configset - Zookeeper only? What about for non SolrCloud installations

          There is no concept of a configset outside of SolrCloud

          Non-distributed collection terminology - Is it still collection or core? Or both

          The core APIs will continue to exist. So , both

          What's SMILE? Takes a while to find reference to some binary JSON,

          It is not added as a part of v2 API. It already exists

          HJSON or HOCON (misspelling or two different things?)

          HJSON actually. We want to be as forgiving as possible

          Operations are specified using snake case using either a dash or underscore - Who is making this choice? Are some operations defined one way and others the other?

          They already exist. It is not added i V2 API

          /v2/admin was already discussed for static resources, the spec should be updated if that's accepted as the solution

          The spec is not a complete future plan. We have a lot of missing pieces. The objective is to include as much as possible and make a first release

          Still talks about /solr/v2

          It is /solr/v2

          Is Schema auto-generated from something or manually written?

          It is manually written. it is a part of the source code. Please check the apiv2 branch

          A lot of stuff do not yet support schema . As of now only coponents with end points (request handlers ) do have schema

          Does the name parameter support the full Java regex or just star? If just star, there is no point being 'flexible' about. But if it is full regex (e.g. test[a-z][0-9]) , it is worth mentioning.

          config param - return all collections that use the specific ?collection?

          It is the same as the LIST command as of . It neither supports wild card nor regex. We would like to add support on both end points together

          With async, why are we making request to one endpoint but getting its status from another.

          Interesting. We should explore the semantics of supporting the same

          Is there no useful information to be returned when collection is created? Like which nodes it ends up on?

          The responses are same as they are in V1 . Yes , it returns the nodes

          Show
          noble.paul Noble Paul added a comment - Thanks Alexandre Rafalovitch A lot of stuff that is there is the spec is not implemented . The scope is vast. I strongly recommend you to take a look at the branch v2api configset - Zookeeper only? What about for non SolrCloud installations There is no concept of a configset outside of SolrCloud Non-distributed collection terminology - Is it still collection or core? Or both The core APIs will continue to exist. So , both What's SMILE? Takes a while to find reference to some binary JSON, It is not added as a part of v2 API. It already exists HJSON or HOCON (misspelling or two different things?) HJSON actually. We want to be as forgiving as possible Operations are specified using snake case using either a dash or underscore - Who is making this choice? Are some operations defined one way and others the other? They already exist. It is not added i V2 API /v2/admin was already discussed for static resources, the spec should be updated if that's accepted as the solution The spec is not a complete future plan. We have a lot of missing pieces. The objective is to include as much as possible and make a first release Still talks about /solr/v2 It is /solr/v2 Is Schema auto-generated from something or manually written? It is manually written. it is a part of the source code. Please check the apiv2 branch A lot of stuff do not yet support schema . As of now only coponents with end points (request handlers ) do have schema Does the name parameter support the full Java regex or just star? If just star, there is no point being 'flexible' about. But if it is full regex (e.g. test [a-z] [0-9] ) , it is worth mentioning. config param - return all collections that use the specific ?collection? It is the same as the LIST command as of . It neither supports wild card nor regex. We would like to add support on both end points together With async, why are we making request to one endpoint but getting its status from another. Interesting. We should explore the semantics of supporting the same Is there no useful information to be returned when collection is created? Like which nodes it ends up on? The responses are same as they are in V1 . Yes , it returns the nodes
          Hide
          noble.paul Noble Paul added a comment -

          Thanks Steve Rowe

          I shall post a detailed response after I go through all of them

          Show
          noble.paul Noble Paul added a comment - Thanks Steve Rowe I shall post a detailed response after I go through all of them
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 327aaffae4bd32df6f591a5a3c823ad19fb18df5 in lucene-solr's branch refs/heads/apiv2 from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=327aaff ]

          SOLR-8029 : Addressing a few feedback back comments by steve. The rest to follow
 


          * "int" is used instead of "integer" in schemas (json-schema requires "integer")

          * JsonSchemaValidator has no "integer" support, only "number" (e.g. no INTEGER in JsonSchemaValidator.Type, ApiBag.KNOWN_TYPES)

          * JsonSchemaValidator doesn't validate type values - using an invalid type gives an NPE instead of a useful error message

          * JsonValidatorTest is incomplete: it should test all supported schema validation aspects

          * Did you explore existing JSON validation libraries (instead of implementing from scratch)?

          * JsonSchemaValidator

          * Class javadocs should fully describe the limitations it has compared to full JSON schema support

          * Type.valdateData() is misspelled, should be validateData()

          * Attribute.validateData is unused, should be removed

          * Attribute class name is too vague - it could be named SchemaNode instead, since it represents a node in a JSON schema graph.

          * ObjectAttribute class name is too vague - it could be named SchemaAttribute instead, since it is a set of schema object attribute validators 

          * /url/path appears to be an orphan in many *.json files 

          * These orphaned spec files should be removed:

          * cores.core.Commands.requestRecovery.json (directly specified in cores.core.Commands.json)

          * cores.json (handled by cores.Status.json)

          * cluster.config.Commands.json:

          * "delete" command should be removed, since that functionality is covered by cluster.config.delete.json

          * cluster.security.RuleBasedAuthorization.json:

          * /commands/delete-permission:

          * "type" key is present twice - "type":"object" should be removed (since it should be "int")

          * collections.Commands.json:

          * description is spelled "Description" (capital "D") but should be lowercase

          * description is a copy-paste-o:"The add-field command adds a new field definition to your schema."


          Show
          jira-bot ASF subversion and git services added a comment - Commit 327aaffae4bd32df6f591a5a3c823ad19fb18df5 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=327aaff ] SOLR-8029 : Addressing a few feedback back comments by steve. The rest to follow
 
 * "int" is used instead of "integer" in schemas (json-schema requires "integer")
 * JsonSchemaValidator has no "integer" support, only "number" (e.g. no INTEGER in JsonSchemaValidator.Type, ApiBag.KNOWN_TYPES)
 * JsonSchemaValidator doesn't validate type values - using an invalid type gives an NPE instead of a useful error message
 * JsonValidatorTest is incomplete: it should test all supported schema validation aspects
 * Did you explore existing JSON validation libraries (instead of implementing from scratch)?
 * JsonSchemaValidator
 * Class javadocs should fully describe the limitations it has compared to full JSON schema support
 * Type.valdateData() is misspelled, should be validateData()
 * Attribute.validateData is unused, should be removed
 * Attribute class name is too vague - it could be named SchemaNode instead, since it represents a node in a JSON schema graph.
 * ObjectAttribute class name is too vague - it could be named SchemaAttribute instead, since it is a set of schema object attribute validators 
 * /url/path appears to be an orphan in many *.json files 
 * These orphaned spec files should be removed:
 * cores.core.Commands.requestRecovery.json (directly specified in cores.core.Commands.json)
 * cores.json (handled by cores.Status.json)
 * cluster.config.Commands.json:
 * "delete" command should be removed, since that functionality is covered by cluster.config.delete.json
 * cluster.security.RuleBasedAuthorization.json:
 * /commands/delete-permission:
 * "type" key is present twice - "type":"object" should be removed (since it should be "int")
 * collections.Commands.json:
 * description is spelled "Description" (capital "D") but should be lowercase
 * description is a copy-paste-o:"The add-field command adds a new field definition to your schema."

          Hide
          varunthacker Varun Thacker added a comment -

          Hi Noble,

          One suggestion regarding a param in the ADDREPLICA Collections API

          We currently have a param called "node" which basically can be used to tell Solr which node to create the replica.
          In the cluster state , the param gets stored as "node_name" . So for a user who calls CLUSTERSTATUS he now sees the value as "node_name" . It would be nicer if ADDREPLICA command renamed the param from "node" to "node_name" just to make it more consistent I believe.

          Similarly Add Role / Delete node takes "node" as well.

          Show
          varunthacker Varun Thacker added a comment - Hi Noble, One suggestion regarding a param in the ADDREPLICA Collections API We currently have a param called "node" which basically can be used to tell Solr which node to create the replica. In the cluster state , the param gets stored as "node_name" . So for a user who calls CLUSTERSTATUS he now sees the value as "node_name" . It would be nicer if ADDREPLICA command renamed the param from "node" to "node_name" just to make it more consistent I believe. Similarly Add Role / Delete node takes "node" as well.
          Hide
          noble.paul Noble Paul added a comment -

          👍

          Show
          noble.paul Noble Paul added a comment - 👍
          Hide
          jira-bot ASF subversion and git services added a comment -

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

          SOLR-8029: more feedback from Steve addressed. ADDROLE, REMOVEROLE commands added

          Show
          jira-bot ASF subversion and git services added a comment - Commit baec97036a2c0413830f0717f5adf1d7871b5b3c in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=baec970 ] SOLR-8029 : more feedback from Steve addressed. ADDROLE, REMOVEROLE commands added
          Hide
          jira-bot ASF subversion and git services added a comment -

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

          SOLR-8029: Merge remote-tracking branch 'remotes/origin/master' into apiv2

          Show
          jira-bot ASF subversion and git services added a comment - Commit b49d9027b346e65853f6d1210f45d5c918760e70 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b49d902 ] SOLR-8029 : Merge remote-tracking branch 'remotes/origin/master' into apiv2
          Hide
          jira-bot ASF subversion and git services added a comment -

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

          SOLR-8029: Merge remote-tracking branch 'remotes/origin/master' into apiv2

          Show
          jira-bot ASF subversion and git services added a comment - Commit d83b6b8022d3c023344d6b1efd74e2c2f972a8c7 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=d83b6b8 ] SOLR-8029 : Merge remote-tracking branch 'remotes/origin/master' into apiv2
          Hide
          jira-bot ASF subversion and git services added a comment -

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

          SOLR-8029: added , commands add-role, remove-role, clusterprop

          Show
          jira-bot ASF subversion and git services added a comment - Commit ea739f7350b0971249267532e30e979116754d2e in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ea739f7 ] SOLR-8029 : added , commands add-role, remove-role, clusterprop
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 66f09139197ce54292dc103e2d66b1b384bb79a6 in lucene-solr's branch refs/heads/apiv2 from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=66f0913 ]

          SOLR-8029: 'enum' support in schema

          Show
          jira-bot ASF subversion and git services added a comment - Commit 66f09139197ce54292dc103e2d66b1b384bb79a6 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=66f0913 ] SOLR-8029 : 'enum' support in schema
          Hide
          jira-bot ASF subversion and git services added a comment -

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

          SOLR-8029: general refactoring

          Show
          jira-bot ASF subversion and git services added a comment - Commit cf1bbc3d74fd11f81e6fa51c5c5f205fdc4e2c21 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=cf1bbc3 ] SOLR-8029 : general refactoring
          Hide
          jira-bot ASF subversion and git services added a comment -

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

          SOLR-8029: balanceshardunique added

          Show
          jira-bot ASF subversion and git services added a comment - Commit c47ea512b8d483a8ccf47373ce6a6e4028a5ecca in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c47ea51 ] SOLR-8029 : balanceshardunique added
          Hide
          jira-bot ASF subversion and git services added a comment -

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

          SOLR-8029: moved the set-replica to collections/collection level

          Show
          jira-bot ASF subversion and git services added a comment - Commit bbb44137e1f457b02f47ce0798d4d213d964d8cb in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=bbb4413 ] SOLR-8029 : moved the set-replica to collections/collection level
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 4f53c9411eca4927f75471be5f089d5ade6c8251 in lucene-solr's branch refs/heads/apiv2 from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4f53c94 ]

          SOLR-8029: renamed a couple of core commands and added a testcase for ValidatingJsonMap

          Show
          jira-bot ASF subversion and git services added a comment - Commit 4f53c9411eca4927f75471be5f089d5ade6c8251 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4f53c94 ] SOLR-8029 : renamed a couple of core commands and added a testcase for ValidatingJsonMap
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 2551c7997947f6abc7912b659ad3ceb393c3b931 in lucene-solr's branch refs/heads/apiv2 from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2551c79 ]

          SOLR-8029:added missing attribute

          Show
          jira-bot ASF subversion and git services added a comment - Commit 2551c7997947f6abc7912b659ad3ceb393c3b931 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2551c79 ] SOLR-8029 :added missing attribute
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 9d18a538ffb7e095a4dc1181670da7139842e5a5 in lucene-solr's branch refs/heads/apiv2 from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9d18a53 ]

          SOLR-8029:test failure addressed

          Show
          jira-bot ASF subversion and git services added a comment - Commit 9d18a538ffb7e095a4dc1181670da7139842e5a5 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9d18a53 ] SOLR-8029 :test failure addressed
          Hide
          jira-bot ASF subversion and git services added a comment -

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

          SOLR-8029:test failure addressed

          Show
          jira-bot ASF subversion and git services added a comment - Commit befedca2d63a1abdd7989f75d9e2af0678a2b96d in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=befedca ] SOLR-8029 :test failure addressed
          Hide
          jira-bot ASF subversion and git services added a comment -

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

          SOLR-8029: cleaning up specs

          Show
          jira-bot ASF subversion and git services added a comment - Commit db048321565bbc2cfa92192372c782659ff21521 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=db04832 ] SOLR-8029 : cleaning up specs
          Hide
          jira-bot ASF subversion and git services added a comment -

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

          SOLR-8029: more cleanup of specs

          Show
          jira-bot ASF subversion and git services added a comment - Commit e0a09f5370ae770f7aeca474970969f70e30b9c8 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e0a09f5 ] SOLR-8029 : more cleanup of specs
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 3baf6f8b3002e550400781194c4ef88a248f2ef9 in lucene-solr's branch refs/heads/apiv2 from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=3baf6f8 ]

          SOLR-8029: more cleanup of specs. renamed collections.json collections.collection.json

          Show
          jira-bot ASF subversion and git services added a comment - Commit 3baf6f8b3002e550400781194c4ef88a248f2ef9 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=3baf6f8 ] SOLR-8029 : more cleanup of specs. renamed collections.json collections.collection.json
          Hide
          jira-bot ASF subversion and git services added a comment -

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

          SOLR-8029: testcases for configset api

          Show
          jira-bot ASF subversion and git services added a comment - Commit b957e2ed1f28038e6b0f07dc0f74319d89cb16c2 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b957e2e ] SOLR-8029 : testcases for configset api
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 4e879baf99b3426529e6a0f176fcfc50a1687716 in lucene-solr's branch refs/heads/apiv2 from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4e879ba ]

          SOLR-8029: Simplified the /_introspect code and fixed a couple of bugs

          Show
          jira-bot ASF subversion and git services added a comment - Commit 4e879baf99b3426529e6a0f176fcfc50a1687716 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4e879ba ] SOLR-8029 : Simplified the /_introspect code and fixed a couple of bugs
          Hide
          jira-bot ASF subversion and git services added a comment -

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

          SOLR-8029: Added more details to config API

          Show
          jira-bot ASF subversion and git services added a comment - Commit c482b339e7813e3b39593bda7c498ecefc547e05 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c482b33 ] SOLR-8029 : Added more details to config API
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 776eae2449450d21b25cef0717d996cdd9b0cce3 in lucene-solr's branch refs/heads/apiv2 from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=776eae2 ]

          SOLR-8029: filling in some missing specs

          Show
          jira-bot ASF subversion and git services added a comment - Commit 776eae2449450d21b25cef0717d996cdd9b0cce3 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=776eae2 ] SOLR-8029 : filling in some missing specs
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 31933ec76005f0656a5a494c18fcb3b22a8ada97 in lucene-solr's branch refs/heads/apiv2 from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=31933ec ]

          SOLR-8029: filling in some missing specs

          Show
          jira-bot ASF subversion and git services added a comment - Commit 31933ec76005f0656a5a494c18fcb3b22a8ada97 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=31933ec ] SOLR-8029 : filling in some missing specs
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 4942f3325e5a1f89a1902b071642163f0c806398 in lucene-solr's branch refs/heads/apiv2 from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4942f33 ]

          SOLR-8029: cleanup code for readability

          Show
          jira-bot ASF subversion and git services added a comment - Commit 4942f3325e5a1f89a1902b071642163f0c806398 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4942f33 ] SOLR-8029 : cleanup code for readability
          Hide
          jira-bot ASF subversion and git services added a comment -

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

          SOLR-8029: refactoring

          Show
          jira-bot ASF subversion and git services added a comment - Commit a919579f42123d626bc4b873325ba1ee37fec479 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a919579 ] SOLR-8029 : refactoring
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 16629175125ef896fa38874739f2e5d38d3cc8e3 in lucene-solr's branch refs/heads/apiv2 from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1662917 ]

          SOLR-8029: typos

          Show
          jira-bot ASF subversion and git services added a comment - Commit 16629175125ef896fa38874739f2e5d38d3cc8e3 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1662917 ] SOLR-8029 : typos
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 84695ff71f33716774b85413eced4d42fb26ad09 in lucene-solr's branch refs/heads/apiv2 from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=84695ff ]

          SOLR-8029: add support for #include in spec files

          Show
          jira-bot ASF subversion and git services added a comment - Commit 84695ff71f33716774b85413eced4d42fb26ad09 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=84695ff ] SOLR-8029 : add support for #include in spec files
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 5e179a18aa4bcb3697e9f4964ff2a01b9f6b082e in lucene-solr's branch refs/heads/apiv2 from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5e179a1 ]

          SOLR-8029: reuse add-fieldtype spec

          Show
          jira-bot ASF subversion and git services added a comment - Commit 5e179a18aa4bcb3697e9f4964ff2a01b9f6b082e in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5e179a1 ] SOLR-8029 : reuse add-fieldtype spec
          Hide
          jira-bot ASF subversion and git services added a comment -

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

          SOLR-8029: more spec

          Show
          jira-bot ASF subversion and git services added a comment - Commit cc21a767b92df6430cd46e2d07253ef50229c61f in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=cc21a76 ] SOLR-8029 : more spec
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 509db5805748e9d8e825f70058d92f6c251aa0f4 in lucene-solr's branch refs/heads/apiv2 from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=509db58 ]

          SOLR-8029: more spec refinements

          Show
          jira-bot ASF subversion and git services added a comment - Commit 509db5805748e9d8e825f70058d92f6c251aa0f4 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=509db58 ] SOLR-8029 : more spec refinements
          Hide
          jira-bot ASF subversion and git services added a comment -

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

          SOLR-8029: more spec refinements

          Show
          jira-bot ASF subversion and git services added a comment - Commit f3b14aebd817e922afc0268d05a8cbbaf6b8a985 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f3b14ae ] SOLR-8029 : more spec refinements
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 5ef717bd97cc1f479dfdf2bdd210f32406c8224d in lucene-solr's branch refs/heads/apiv2 from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5ef717b ]

          SOLR-8029: more spec refinements for schema edit

          Show
          jira-bot ASF subversion and git services added a comment - Commit 5ef717bd97cc1f479dfdf2bdd210f32406c8224d in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5ef717b ] SOLR-8029 : more spec refinements for schema edit
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 47fd4929e60359e3df86966451ce9372dae74fd8 in lucene-solr's branch refs/heads/apiv2 from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=47fd492 ]

          SOLR-8029: more spec refinements for schema read

          Show
          jira-bot ASF subversion and git services added a comment - Commit 47fd4929e60359e3df86966451ce9372dae74fd8 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=47fd492 ] SOLR-8029 : more spec refinements for schema read
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit bf89a7a405138b39d91d4dc31a9a920e4ecf6ff3 in lucene-solr's branch refs/heads/apiv2 from Cassandra Targett
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=bf89a7a ]

          SOLR-8029: Update 'cluster' specs with descriptions and links to docs

          Show
          jira-bot ASF subversion and git services added a comment - Commit bf89a7a405138b39d91d4dc31a9a920e4ecf6ff3 in lucene-solr's branch refs/heads/apiv2 from Cassandra Targett [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=bf89a7a ] SOLR-8029 : Update 'cluster' specs with descriptions and links to docs
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit cedc63d46e5aca384b8b34fbe7c51568ffbe671a in lucene-solr's branch refs/heads/apiv2 from Cassandra Targett
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=cedc63d ]

          SOLR-8029: Modify schemaEdit specs; add include file for analyzers

          Show
          jira-bot ASF subversion and git services added a comment - Commit cedc63d46e5aca384b8b34fbe7c51568ffbe671a in lucene-solr's branch refs/heads/apiv2 from Cassandra Targett [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=cedc63d ] SOLR-8029 : Modify schemaEdit specs; add include file for analyzers
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 6aa57e891aca031b598c085a10d26c1d82e99343 in lucene-solr's branch refs/heads/apiv2 from Steve Rowe
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=6aa57e8 ]

          SOLR-8029: Api spec parsing: Recursively handle '#include' directives in all JSON objects; replace repeated analyzer definitions in the addFieldType spec with a single file included for each of the different types of analyzers; add multiTermAnalyzer key to addFieldType spec.

          Show
          jira-bot ASF subversion and git services added a comment - Commit 6aa57e891aca031b598c085a10d26c1d82e99343 in lucene-solr's branch refs/heads/apiv2 from Steve Rowe [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=6aa57e8 ] SOLR-8029 : Api spec parsing: Recursively handle '#include' directives in all JSON objects; replace repeated analyzer definitions in the addFieldType spec with a single file included for each of the different types of analyzers; add multiTermAnalyzer key to addFieldType spec.
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 6798877180ffc136adbe70a273b3e554df8aa370 in lucene-solr's branch refs/heads/apiv2 from Steve Rowe
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=6798877 ]

          SOLR-8029: remove stray commas in api spec files

          Show
          jira-bot ASF subversion and git services added a comment - Commit 6798877180ffc136adbe70a273b3e554df8aa370 in lucene-solr's branch refs/heads/apiv2 from Steve Rowe [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=6798877 ] SOLR-8029 : remove stray commas in api spec files
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 03eca9c111e68b74e4d9a160bcf5fb3cbc0d3ddf in lucene-solr's branch refs/heads/apiv2 from Steve Rowe
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=03eca9c ]

          SOLR-8029: get introspect working for endpoints that don't include named cores or collections

          Show
          jira-bot ASF subversion and git services added a comment - Commit 03eca9c111e68b74e4d9a160bcf5fb3cbc0d3ddf in lucene-solr's branch refs/heads/apiv2 from Steve Rowe [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=03eca9c ] SOLR-8029 : get introspect working for endpoints that don't include named cores or collections
          Hide
          jira-bot ASF subversion and git services added a comment -

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

          SOLR-8029: avoid infinite loop

          Show
          jira-bot ASF subversion and git services added a comment - Commit b55e25a9900f15db1c5ffbb2f2eb1f09c831f56f in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b55e25a ] SOLR-8029 : avoid infinite loop
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 8c58366684f824465d46a957232664b5a11a1923 in lucene-solr's branch refs/heads/apiv2 from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=8c58366 ]

          SOLR-8029: "shard" property should be required for "split" and "create" commands

          Show
          jira-bot ASF subversion and git services added a comment - Commit 8c58366684f824465d46a957232664b5a11a1923 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=8c58366 ] SOLR-8029 : "shard" property should be required for "split" and "create" commands
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 1fc35c136a953d8cd8ff12cfdffa328040320d73 in lucene-solr's branch refs/heads/apiv2 from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1fc35c1 ]

          SOLR-8029: delete shard parameters added

          Show
          jira-bot ASF subversion and git services added a comment - Commit 1fc35c136a953d8cd8ff12cfdffa328040320d73 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1fc35c1 ] SOLR-8029 : delete shard parameters added
          Hide
          jira-bot ASF subversion and git services added a comment -

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

          SOLR-8029: changed command id to a parameter instead of path segment

          Show
          jira-bot ASF subversion and git services added a comment - Commit d9caa8082c0e04909fd4d6b9095464ed452742b1 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=d9caa80 ] SOLR-8029 : changed command id to a parameter instead of path segment
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 049cb10a21a4fdfa180c1931fdf901c1067f13ab in lucene-solr's branch refs/heads/apiv2 from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=049cb10 ]

          SOLR-8029: _introspect for per core handlers must return the full path

          Show
          jira-bot ASF subversion and git services added a comment - Commit 049cb10a21a4fdfa180c1931fdf901c1067f13ab in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=049cb10 ] SOLR-8029 : _introspect for per core handlers must return the full path
          Hide
          jira-bot ASF subversion and git services added a comment -

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

          SOLR-8029: added a testcase for absolute paths returned by _introspect api

          Show
          jira-bot ASF subversion and git services added a comment - Commit f1bd0f462456b4aa8273b394247c6acbadf9fa3b in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f1bd0f4 ] SOLR-8029 : added a testcase for absolute paths returned by _introspect api
          Hide
          jira-bot ASF subversion and git services added a comment -

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

          SOLR-8029: improve /_introspect support for urls with trailing variables such as /blob/

          {name}
          Show
          jira-bot ASF subversion and git services added a comment - Commit de325d98cfb86304eed299f9f794786b4bbf24a2 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=de325d9 ] SOLR-8029 : improve /_introspect support for urls with trailing variables such as /blob/ {name}
          Hide
          jira-bot ASF subversion and git services added a comment -

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

          SOLR-8029: spec improvements

          Show
          jira-bot ASF subversion and git services added a comment - Commit caebda946abf237a97bf844fdcc5623ee4dec2eb in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=caebda9 ] SOLR-8029 : spec improvements
          Hide
          jira-bot ASF subversion and git services added a comment -

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

          SOLR-8029: spec improvements

          Show
          jira-bot ASF subversion and git services added a comment - Commit b1c49bc9d6287a2453ced2432fe7e008a5f8593f in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b1c49bc ] SOLR-8029 : spec improvements
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 5fe6090f3e42f51be8a9c164b515ffcb7fdf5835 in lucene-solr's branch refs/heads/apiv2 from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5fe6090 ]

          SOLR-8029: spec improvements

          Show
          jira-bot ASF subversion and git services added a comment - Commit 5fe6090f3e42f51be8a9c164b515ffcb7fdf5835 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5fe6090 ] SOLR-8029 : spec improvements
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 09d1a8f0c00bbad82f659051acd161b523e2746e in lucene-solr's branch refs/heads/apiv2 from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=09d1a8f ]

          SOLR-8029: spec improvements

          Show
          jira-bot ASF subversion and git services added a comment - Commit 09d1a8f0c00bbad82f659051acd161b523e2746e in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=09d1a8f ] SOLR-8029 : spec improvements
          Hide
          jira-bot ASF subversion and git services added a comment -

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

          SOLR-8029: spec improvements

          Show
          jira-bot ASF subversion and git services added a comment - Commit e199495c4344e6c8e8861d43ab819cd451e9f1f1 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e199495 ] SOLR-8029 : spec improvements
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 4d04cc85d69af51179d0ef9269b21859ed7b2861 in lucene-solr's branch refs/heads/apiv2 from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4d04cc8 ]

          SOLR-8029: variable names changed

          Show
          jira-bot ASF subversion and git services added a comment - Commit 4d04cc85d69af51179d0ef9269b21859ed7b2861 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4d04cc8 ] SOLR-8029 : variable names changed
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 4ddaba397d30f9b5344545d08c809488633638d1 in lucene-solr's branch refs/heads/apiv2 from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4ddaba3 ]

          SOLR-8029: fixing some test errors

          Show
          jira-bot ASF subversion and git services added a comment - Commit 4ddaba397d30f9b5344545d08c809488633638d1 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4ddaba3 ] SOLR-8029 : fixing some test errors
          Hide
          jira-bot ASF subversion and git services added a comment -

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

          SOLR-8029: fixing some test errors

          Show
          jira-bot ASF subversion and git services added a comment - Commit c91b96211b9e88c6cc7a4e3aedc14e4f1375dab8 in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c91b962 ] SOLR-8029 : fixing some test errors
          Hide
          noble.paul Noble Paul added a comment -

          I'm planning to commit this to master shortly

          Show
          noble.paul Noble Paul added a comment - I'm planning to commit this to master shortly
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment -

          I'm planning to commit this to master shortly

          +1. Yay, this is exciting!

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - I'm planning to commit this to master shortly +1. Yay, this is exciting!
          Hide
          dsmiley David Smiley added a comment -

          Exciting indeed Congrats Noble & everyone else for working so hard on it.

          Show
          dsmiley David Smiley added a comment - Exciting indeed Congrats Noble & everyone else for working so hard on it.
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 5a8dfd96a28bc316d74b5b7e74b28f16b5bd3f4b in lucene-solr's branch refs/heads/apiv2 from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5a8dfd9 ]

          SOLR-8029: fixing precommit errors

          Show
          jira-bot ASF subversion and git services added a comment - Commit 5a8dfd96a28bc316d74b5b7e74b28f16b5bd3f4b in lucene-solr's branch refs/heads/apiv2 from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5a8dfd9 ] SOLR-8029 : fixing precommit errors
          Hide
          noble.paul Noble Paul added a comment -

          patch with all tests , precommit passing.

          Show
          noble.paul Noble Paul added a comment - patch with all tests , precommit passing.
          Hide
          arafalov Alexandre Rafalovitch added a comment -

          Awesome news.

          So, is this now fully implementing original specs and answering all issue questions? Or is there a newer document reflecting the actual implementation.

          How do we review this, apart from pure code-reading?

          Show
          arafalov Alexandre Rafalovitch added a comment - Awesome news. So, is this now fully implementing original specs and answering all issue questions? Or is there a newer document reflecting the actual implementation. How do we review this, apart from pure code-reading?
          Hide
          noble.paul Noble Paul added a comment -

          Alexandre Rafalovitch Good question.

          It's unlikely that it sticks to the original documentation fully.

          I shall just put up a small one pager for folks who wish to review this quickly

          Show
          noble.paul Noble Paul added a comment - Alexandre Rafalovitch Good question. It's unlikely that it sticks to the original documentation fully. I shall just put up a small one pager for folks who wish to review this quickly
          Hide
          noble.paul Noble Paul added a comment -

          Refer to this document. This is not fully updated and some of the items marked as "missing" are actually implemented.
          https://docs.google.com/document/d/18n9IL6y82C8gnBred6lzG0GLaT3OsZZsBvJQ2YAt72I/edit?usp=sharing

          Show
          noble.paul Noble Paul added a comment - Refer to this document. This is not fully updated and some of the items marked as "missing" are actually implemented. https://docs.google.com/document/d/18n9IL6y82C8gnBred6lzG0GLaT3OsZZsBvJQ2YAt72I/edit?usp=sharing
          Hide
          jira-bot ASF subversion and git services added a comment -

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

          SOLR-8029: Added new style APIs and a framework for creating new APIs and mapping old APIs to new

          Show
          jira-bot ASF subversion and git services added a comment - Commit 71abe130697b0f279d6e3613145f1f8f052c7848 in lucene-solr's branch refs/heads/master from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=71abe13 ] SOLR-8029 : Added new style APIs and a framework for creating new APIs and mapping old APIs to new
          Hide
          jira-bot ASF subversion and git services added a comment -

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

          SOLR-8029: test failures fixed

          Show
          jira-bot ASF subversion and git services added a comment - Commit eb42834617a6fde7bc5f7a0c1ccbf1c9cce10e83 in lucene-solr's branch refs/heads/master from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=eb42834 ] SOLR-8029 : test failures fixed
          Hide
          noble.paul Noble Paul added a comment -

          Things looks stable and I plan to port it to branch_6x. Any inputs, feedback are welcome. Especially on the framework, configuration etc. If there are missing APIs we can open a ticket and fix them seperately

          Show
          noble.paul Noble Paul added a comment - Things looks stable and I plan to port it to branch_6x. Any inputs, feedback are welcome. Especially on the framework, configuration etc. If there are missing APIs we can open a ticket and fix them seperately
          Hide
          jira-bot ASF subversion and git services added a comment -

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

          SOLR-8029: Added new style APIs and a framework for creating new APIs and mapping old APIs to new

          Show
          jira-bot ASF subversion and git services added a comment - Commit d72634813b2e9014b70ce753a02c8d7297af8c81 in lucene-solr's branch refs/heads/branch_6x from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=d726348 ] SOLR-8029 : Added new style APIs and a framework for creating new APIs and mapping old APIs to new
          Hide
          romseygeek Alan Woodward added a comment -

          Hey Noble Paul, this is failing on the Java 9 Jenkins runs because TestCoreAdminApis uses EasyMock (see SOLR-9893 and SOLR-9966). You need to use Mockito instead.

          Show
          romseygeek Alan Woodward added a comment - Hey Noble Paul , this is failing on the Java 9 Jenkins runs because TestCoreAdminApis uses EasyMock (see SOLR-9893 and SOLR-9966 ). You need to use Mockito instead.
          Hide
          noble.paul Noble Paul added a comment -

          sure Alan Woodward . I'll fix it

          Show
          noble.paul Noble Paul added a comment - sure Alan Woodward . I'll fix it
          Hide
          jira-bot ASF subversion and git services added a comment -

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

          SOLR-8029: disabled easymock for java9

          Show
          jira-bot ASF subversion and git services added a comment - Commit 563f522643b5460e5b3bde1815f3f0b08c248eef in lucene-solr's branch refs/heads/master from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=563f522 ] SOLR-8029 : disabled easymock for java9
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 8b5dec52f5d331ad3febd599016f8dd85480e628 in lucene-solr's branch refs/heads/branch_6x from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=8b5dec5 ]

          SOLR-8029: disabled easymock for java9

          Show
          jira-bot ASF subversion and git services added a comment - Commit 8b5dec52f5d331ad3febd599016f8dd85480e628 in lucene-solr's branch refs/heads/branch_6x from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=8b5dec5 ] SOLR-8029 : disabled easymock for java9
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 5c4ee10683fab338f3f4619a850d509c716ebe33 in lucene-solr's branch refs/heads/branch_6x from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5c4ee10 ]

          SOLR-8029: introspect was not showing for certain collection apis

          Show
          jira-bot ASF subversion and git services added a comment - Commit 5c4ee10683fab338f3f4619a850d509c716ebe33 in lucene-solr's branch refs/heads/branch_6x from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5c4ee10 ] SOLR-8029 : introspect was not showing for certain collection apis
          Hide
          jira-bot ASF subversion and git services added a comment -

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

          SOLR-8029: introspect was not showing for certain collection apis

          Show
          jira-bot ASF subversion and git services added a comment - Commit 65c6c576b720b19029a10bf14f81d4de23302863 in lucene-solr's branch refs/heads/master from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=65c6c57 ] SOLR-8029 : introspect was not showing for certain collection apis
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 9a1702a8f5b5496893a99c4e1f39cd58520786ae in lucene-solr's branch refs/heads/master from Ishan Chattopadhyaya
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9a1702a ]

          SOLR-8029: Reverting the previous commit and the merge

          Show
          jira-bot ASF subversion and git services added a comment - Commit 9a1702a8f5b5496893a99c4e1f39cd58520786ae in lucene-solr's branch refs/heads/master from Ishan Chattopadhyaya [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9a1702a ] SOLR-8029 : Reverting the previous commit and the merge
          Hide
          jira-bot ASF subversion and git services added a comment -

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

          SOLR-8029: introspect was not showing for certain collection apis

          Show
          jira-bot ASF subversion and git services added a comment - Commit 2470fbaa0ee4d1a211957bc47242bd081a31234d in lucene-solr's branch refs/heads/master from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2470fba ] SOLR-8029 : introspect was not showing for certain collection apis
          Hide
          ctargett Cassandra Targett added a comment -

          Noble Paul - Since the new APIs were included with Solr 6.5, and there is SOLR-10432 for follow-on items, this should be resolved, right?

          Show
          ctargett Cassandra Targett added a comment - Noble Paul - Since the new APIs were included with Solr 6.5, and there is SOLR-10432 for follow-on items, this should be resolved, right?

            People

            • Assignee:
              noble.paul Noble Paul
              Reporter:
              noble.paul Noble Paul
            • Votes:
              2 Vote for this issue
              Watchers:
              30 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development