[ 
https://issues.apache.org/jira/browse/SOLR-3038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Shawn Heisey updated SOLR-3038:
-------------------------------

    Attachment: SOLR-3038-abstract-writer.patch

Updated patch to fix some test failures.  I am seeing some test failures that 
do not seem related to my patch - they are things that I have been seeing from 
Jenkins.

I think BasicHttpSolrServerTest needs at least one more test that also tests 
XMLRequestWriter, I'll think about that.

SolrExampleStreamingTest was explicitly setting the XML writer.  My patch 
continues to do that, but I'm wondering if it needs an additional test for 
Binary.

This patch is absolutely what I think we need for trunk.  I'd like to do the 
same to 4x, but I'm worried that it isn't OK to break code where RequestWriter 
is explicitly used.  Code that uses BinaryRequestWriter would not need 
adjustment.  If that breakage sounds too dangerous, we could do the one-line 
fix for 4x.

Abstract classes are a somewhat new area for me.  Is my implementation 
acceptable?
                
> Solrj should use javabin wireformat by default with updaterequests
> ------------------------------------------------------------------
>
>                 Key: SOLR-3038
>                 URL: https://issues.apache.org/jira/browse/SOLR-3038
>             Project: Solr
>          Issue Type: Improvement
>          Components: clients - java
>    Affects Versions: 4.0-ALPHA
>            Reporter: Sami Siren
>            Priority: Minor
>         Attachments: SOLR-3038-abstract-writer.patch, 
> SOLR-3038-abstract-writer.patch, SOLR-3038-abstract-writer.patch
>
>
> The javabin wire format is faster than xml when feeding Solr - it should 
> become the default. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to