Yes, this shows up in the update syntax as well with add, add, add, delete, add in the JSON. Solr also tolerates extra trailing commas in lists, which is more tolerant than the spec https://www.json.org/json-en.html
I think the idea is to allow JSON to stream name/value pairs without the need to keep a record of what is seen and enforce uniqueness which would hurt performance. I'm not a fan of this design in Solr either since almost every default implementation in every language incorrectly assumes JSON is a Map structure by default, and JSON with duplicate names really doesn't map well to objects in object oriented languages which never allow duplicate property names, but backwards compatibility is also important so it's not likely to change any time soon. On Thu, Feb 19, 2026 at 7:49 AM Thomas Corthals <[email protected]> wrote: > Hi Dmitri > > The JSON standard (ECMA 404) does in fact allow duplicate keys (they call > them names) in objects. > > "The JSON syntax does not impose any restrictions on the strings used as > names, does not require that name strings be unique, and does not assign > any significance to the ordering of name/value pairs." > > But it's really annoying when you're working in a programming language that > doesn't have a data structure that supports this. > > > Thomas > > Op do 19 feb 2026 om 02:11 schreef Dmitri Maziuk <[email protected] > >: > > > Hi all, > > > > I'm still trying to make sense of "everything API" Solr 9 and finding > > The Fine Manual a bit sketchy. > > > > Given a handler that returns multiple facets by default: > > ``` > > <str name="facet.mincount">1</str> > > <str name="facet.limit">8</str> > > <str name="facet.field">subject</str> > > <str name="facet.field">country</str> > > <str name="facet.field">state</str> > > <str name="facet.field">county</str> > > <str name="facet.field">community</str> > > <str name="facet.field">decade</str> > > ``` > > exactly what Solr's add-requesthandler "JSON" should look like? > > > > I've JSON in quotes because last I looked Solr allowed duplicate keys > > and this may be Solr-valid: > > ``` > > { > > "facet.mincount" : 1, > > "facet.limit" : 8, > > "facet.field" : "subject", > > "facet.field" : "country", > > ... > > } > > ``` > > Or should it be JSON-proper: > > ``` > > { > > "facet.mincount" : 1, > > "facet.limit" : 8, > > "facet.field" : ["subject", "country", ... ] > > } > > ``` > > ??? > > > > What about this little gem: > > ``` > > <lst name="defaults"> > > ... > > <!-- define this since you reference it --> > > <str name="BOOST_BF"></str> > > </lst> > > <lst name="invariants"> > > <str name="q"> > > ( > > /* parent matches */ > > _query_:"{!edismax > > qf=$BOOST_QF > > pf=$BOOST_PF > > pf2=$BOOST_PF2 > > pf3=$BOOST_PF3 > > pf4=$BOOST_PF4 > > ps=$ps > > ps2=$ps2 > > ps3=$ps3 > > ps4=$ps4 > > bq=$BOOST_BQ > > bf=$BOOST_BF > > v=$search_params}" > > OR > > /* child matches -> return + score parent */ > > _query_:"{!parent which=is_child:false score=max} > > ( > > is_child:true AND {!edismax > > qf=$BOOST_QF > > pf=$BOOST_PF > > pf2=$BOOST_PF2 > > pf3=$BOOST_PF3 > > pf4=$BOOST_PF4 > > ps=$ps > > ps2=$ps2 > > ps3=$ps3 > > ps4=$ps4 > > bq=$BOOST_BQ > > bf=$BOOST_BF > > v=$search_params} > > )"^0.5 > > ) > > </str> > > </lst> > > ``` > > What would that look like: `"BOOST_BF":null` in the defaults and > > > `"q":"that-whole-thing-in-one-long-string-with-quotes-escaped-with-backslashes"` > > > > in the invariants? > > > > Any ideas? > > > > Or can I just POST 'Content-Type: text/xml' to some API endpoint? > > > > TIA > > (I haven't had a chance to play more with security.json, BTW, it's still > > on my todo list) > > > > DIma > > > > > > > -- http://www.needhamsoftware.com (work) https://a.co/d/b2sZLD9 (my fantasy fiction book)
