So I found out the issue here... It was related to what you guys said regarding the Map object in my document. The problem is that I had data being serialized from DB -> .NET -> JSON and some of the fields in .NET was == System.DBNull.Value instead of null. This caused the JSON serializer to write out an object (ie. Map) so when these fields got deserialized into the SolrInputDocument it had the Map objects as you indicated.
Thanks for the help! Much appreciated! On Sat, Oct 19, 2013 at 12:58 AM, Jack Krupansky <j...@basetechnology.com>wrote: > By all means please do file a support request with DataStax, either as an > official support ticket or as a question on StackOverflow. > > But, I do think the previous answer of avoiding the use of a Map object in > your document is likely to be the solution. > > > -- Jack Krupansky > > -----Original Message----- From: Brent Ryan > Sent: Friday, October 18, 2013 10:21 PM > To: solr-user@lucene.apache.org > Subject: Re: SOLRJ replace document > > > So I think the issue might be related to the tech stack we're using which > is SOLR within DataStax enterprise which doesn't support atomic updates. > But I think it must have some sort of bug around this because it doesn't > appear to work correctly for this use case when using solrj ... Anyways, > I've contacted support so lets see what they say. > > > On Fri, Oct 18, 2013 at 5:51 PM, Shawn Heisey <s...@elyograg.org> wrote: > > On 10/18/2013 3:36 PM, Brent Ryan wrote: >> >> My schema is pretty simple and has a string field called solr_id as my >>> unique key. Once I get back to my computer I'll send some more details. >>> >>> >> If you are trying to use a Map object as the value of a field, that is >> probably why it is interpreting your add request as an atomic update. If >> this is the case, and you're doing it because you have a multivalued >> field, >> you can use a List object rather than a Map. >> >> If this doesn't sound like what's going on, can you share your code, or a >> simplification of the SolrJ parts of it? >> >> Thanks, >> Shawn >> >> >> >
