Re: A question about some behavior I am seeing

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

Timeout on LTR query causing out of memory

Hi Solr Users, Is there an alternative way to time limit an LTR query and request main ranker results if a reranker such as an LTR query takes more time than allowed? I see there is a SOLR-14607 regarding LTR time allowed issue, but it is ope

Re: A question about some behavior I am seeing

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 requir

Re: A question about some behavior I am seeing

Hi Shawn, 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

A question about some behavior I am seeing

In SolrJ 4.7.2, if an atomic update request is sent with some fields set to null (the object, not the string), then those fields will be ignored when processing the atomic update -- no change. In SolrJ 9, a field set to null in an atomic update request will be removed from the document. This