Eirik Lygre created SOLR-9230:
---------------------------------
Summary: Change of default to BinaryRequestWriter breaks some use
cases
Key: SOLR-9230
URL: https://issues.apache.org/jira/browse/SOLR-9230
Project: Solr
Issue Type: Bug
Affects Versions: 6.0
Reporter: Eirik Lygre
>From Solr 6.0 onwards, SOLR-8595 changes the default writer in HttpSolrClient
>(et al) from RequestWriter to BinaryRequestWriter.
The RequestWriter writes java.math.BigDecimal values using a simple toString()
on the value. This means that a BigDecimal-value is passed to the server using
its text representation, which is then mapped into whatever the server wants.
(The RequestWriter probably uses toString() on anything it sees)
The BinaryRequestWriter instead handles unknown value types by writing a string
containing the class name, a colon, and then the toString() value. This means
that a BigDecimal-value is passed to the server as a text representation
"java.math.BigDecimal:12345", which the server cannot convert to a number, and
which then stops indexing.
I'm not entirely sure that this behaviour is a bug, but I'm fairly sure that
the quiet change of behaviour qualifies. The "Trivial Patch" (quote from
SOLR-8595) isn't, when straight forward indexing scenarios quietly stop working.
There are several possible paths forward:
* Have the BinaryRequestWriter (really the JavaBinCodec) encode
java.lang.Numbers as Strings, the way the RequestWriter does
* Add something in release notes to inform users about the change
SOLR-4021 describes the problem, but the change of default writer increases
problem visibility. SOLR-6165 somehow seems relevant.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
