I understand you have a situation where doing the right thing causes wrong results :) Well, if the client code is not localized to a particular service, I would tackle it from the server side via a custom update processor extending the UpdateRequestProcessorFactory and adding it to a custom update chain in the solrconfig. This processor would check for such null fields in the solr doc and remove them altogether before it makes it further down the chain.
-Rahul On Tue, Sep 26, 2023 at 5:56 PM Shawn Heisey <apa...@elyograg.org.invalid> wrote: > On 9/26/23 14:06, Rahul Goswami wrote: > > I typically set the field value to null in an atomic update if I want to > > remove the field. Eg: If a document is soft deleted via a field > > "isVisible":false , then I would want to drop its "content" field by > > setting it to null (since it is large and not required anymore) in an > > atomic update. > > So as a product behaviour, I am always expecting the behavior you > mentioned > > for SolrJ 9. > > I am dealing with a customer that has a number of homegrown Java > services using SolrJ to talk to Solr. > > From what I have seen, they have been relying on what I would call > incorrect behavior in Solr and SolrJ 4.7. On setting up new > environments using Solr and SolrJ version 9, suddenly the system does > not behave the same. > > It's very much a "how did this EVER work?" situation ... and I keep > finding it hard to believe that their developers would have actually > intended to do the things that have been observed. > > Thanks, > Shawn > >
