Activity

Is there a historic reason for not having a common interface/abstract class for SolrDocument and SolrInputDocument other than a Map?
Since having this right now might break backcompat, does it make sense to do this for 6.0?
Right now, the motivation for doing this is SOLR-8220, but not strictly needed.

Ishan Chattopadhyaya
added a comment - 25/Nov/15 04:48 - edited Is there a historic reason for not having a common interface/abstract class for SolrDocument and SolrInputDocument other than a Map?
Since having this right now might break backcompat, does it make sense to do this for 6.0?
Right now, the motivation for doing this is SOLR-8220 , but not strictly needed.

Ishan Chattopadhyaya
added a comment - 25/Nov/15 08:28 It seems there is no backcompat implications. Spoke to Noble Paul offline, and mentioned that there is no backcompat issue with this change as long as any existing method is not deleted or altered.
Here's a patch adding a SolrDocumentBase as an abstract class which SolrDocument and SolrInputDocument now extend from.

Shalin Shekhar Mangar
added a comment - 02/Dec/15 14:24 With this change, can we remove org.apache.solr.client.solrj.util.ClientUtils#toSolrInputDocument method? And org.apache.solr.client.solrj.util.ClientUtils#toSolrDocument ?
We can deprecate those in 5.x and remove in trunk.
Ishan Chattopadhyaya - SolrDocument used to be serializable but you have removed that in your patch. Same for SolrInputDocument. That is a compat-break. Can you put that back?

When upgrade Apache Solr from version 4.10 to 5.0.0, the parse serialization is not working from SolrDocument class to json.
we use library com.fasterxml.jackson.core:jackson-databind:2.5.4 for json parsing. We are getting this exception:

Ishan Chattopadhyaya
added a comment - 10/Nov/16 16:33 This change was introduced in Solr 5.5 and should not affect 4.10 to 5.0 upgrade. Maybe the solr-users list might be better in terms of offering solutions for the problem you faced?