Solr
  1. Solr
  2. SOLR-867

move EmbeddedSolrServer#getParsedResponse to utility class

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.4
    • Component/s: clients - java
    • Labels:
      None

      Description

      The utility function: EmbeddedSolrServer#getParsedResponse should be moved to a utiltiy class.

        Activity

        Ryan McKinley created issue -
        Ryan McKinley made changes -
        Field Original Value New Value
        Attachment SOLR-867-move-getParsedResponse.patch [ 12394087 ]
        Hide
        Ryan McKinley added a comment -

        This will let us replace:

         solrResponse.setResponse(new EmbeddedSolrServer(request.getCore()).getParsedResponse(request, response));
        

        with:

         solrResponse.setResponse(ClientUtils.getParsedResponse(request, response));
        
        Show
        Ryan McKinley added a comment - This will let us replace: solrResponse.setResponse( new EmbeddedSolrServer(request.getCore()).getParsedResponse(request, response)); with: solrResponse.setResponse(ClientUtils.getParsedResponse(request, response));
        Hide
        Ryan McKinley added a comment -

        my mistake – this can not go in ClientUtils because it requires SolrCore libraries (our package structure is wacked)

        this patch moves the utility function to:
        BinaryResponseWriter.getParsedResponse(req, rsp);

        Show
        Ryan McKinley added a comment - my mistake – this can not go in ClientUtils because it requires SolrCore libraries (our package structure is wacked) this patch moves the utility function to: BinaryResponseWriter.getParsedResponse(req, rsp);
        Ryan McKinley made changes -
        Attachment SOLR-867-move-getParsedResponse.patch [ 12394103 ]
        Ryan McKinley made changes -
        Fix Version/s 1.4 [ 12313351 ]
        Resolution Fixed [ 1 ]
        Status Open [ 1 ] Resolved [ 5 ]
        Hide
        Noble Paul added a comment - - edited

        Why is this done this way ? . The current solution involves the overhead marshalling and unmarshalling. I guess it can be easily avoided.

        you may need to duplicate some code from BinaryResponseWriter#writeDocList(). But the amount of code is minimal

        Show
        Noble Paul added a comment - - edited Why is this done this way ? . The current solution involves the overhead marshalling and unmarshalling. I guess it can be easily avoided. you may need to duplicate some code from BinaryResponseWriter#writeDocList(). But the amount of code is minimal
        Hide
        Ryan McKinley added a comment -

        It has been on the TODO list for a long time.... but I have not had the time/focus for it yet...

        BinaryResponseWriter did not exist when the function first appeared.

        Show
        Ryan McKinley added a comment - It has been on the TODO list for a long time.... but I have not had the time/focus for it yet... BinaryResponseWriter did not exist when the function first appeared.
        Hide
        Noble Paul added a comment -

        I mean the code may remain in BinaryResponseWriter itself. But the problem with the solution is that you end up serializing all those objects and deserializing them.

        If I am not wrong , we only need to recursively go through the NamedList and replace all Doclist and Document with SolrDocumentList and SolrDocument . Every other object remains same at both ends of the pipe.

        So you can reuse the getDoc() method but you may need to replicate the writeDocList() method into a getDocList() method.

        Show
        Noble Paul added a comment - I mean the code may remain in BinaryResponseWriter itself. But the problem with the solution is that you end up serializing all those objects and deserializing them. If I am not wrong , we only need to recursively go through the NamedList and replace all Doclist and Document with SolrDocumentList and SolrDocument . Every other object remains same at both ends of the pipe. So you can reuse the getDoc() method but you may need to replicate the writeDocList() method into a getDocList() method.
        Hide
        Ryan McKinley added a comment -

        Every other object remains same at both ends of the pipe.

        Maybe... there are a few other things that would need to get normalized to have the same output. For example any Map implementation (LinkedHashMap etc) would become a HashMap.

        Show
        Ryan McKinley added a comment - Every other object remains same at both ends of the pipe. Maybe... there are a few other things that would need to get normalized to have the same output. For example any Map implementation (LinkedHashMap etc) would become a HashMap.
        Hide
        Noble Paul added a comment -

        Map implementation (LinkedHashMap etc) would become a HashMap.

        I guess it should not matter. If the object implements map then it should not matter whether it is a LinkedHashMap or even a ConcurrentHashMap

        Show
        Noble Paul added a comment - Map implementation (LinkedHashMap etc) would become a HashMap. I guess it should not matter. If the object implements map then it should not matter whether it is a LinkedHashMap or even a ConcurrentHashMap
        Hide
        Grant Ingersoll added a comment -

        Bulk close for Solr 1.4

        Show
        Grant Ingersoll added a comment - Bulk close for Solr 1.4
        Grant Ingersoll made changes -
        Status Resolved [ 5 ] Closed [ 6 ]

          People

          • Assignee:
            Ryan McKinley
            Reporter:
            Ryan McKinley
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development