Hi Dmitri, I am not sure if I understand your second comment. Can you please elaborate?
I am guessing your first comment is hinting at the value “1” being in String context and hence should be interpreted as false(?) But that would be inconsistent with the documentation and behavior until Solr7.x where it was interpreted as true. As per 8.x documentation: “ Values of 1, t, or T in the first character are interpreted as true. Any other values in the first character are interpreted as false.” So technically even “1blah” should be interpreted as true, and in fact up until 7.x, it is. Many clients send value 1 for some of the boolean fields and the behavior in 8.x breaks backward compatibility (in a possibly critical way. Saying “no” when you mean “yes” can have disastrous consequences). -Rahul On Sun, Aug 28, 2022 at 12:33 PM dmitri maziuk <[email protected]> wrote: > On 2022-08-27 9:47 PM, Rahul Goswami wrote: > > > However, I hit a potential Solr bug where if the String value "1","t" or > > "T" is passed in an atomic update, it is treated as false. > > Why would one want to interpret 1 as true in non-boolean context? (hint, > hint) > > > This doesn't happen though if value "1" is passed in a regular update. > > Eg:Below update reflects the value of inStock as true when queried. > > { > > "id":"test", > > "inStock":"1" > > } > > The bug is, I have 1 in stock. Not 2, not "true", just 1. > > Dima > > >
