@Heitor I believe that you believe you did something that should have unsubscribed, but obviously you did not unsubscribe.
- On this page: https://solr.apache.org/community.html click the unsubscribe button (for *this* list). - That *should* send you an email with a subject starting with " confirm unsubscribe from " - This email will contain instructions to confirm that it was YOU who tried to unsubscribe your email from the list. (from addresses can be forged so, the system guards against others unsubscribing on your behalf the same way it guards against others subscribing on your behalf) - Follow those instructions (typically all you need to do is reply to the confirmation email) and you should get a final email with a subject like "GOODBYE from..." confirming that you are unsubscribed. If you don't get a second goodbye email confirming you are unsubscribed, re-read the instructions and try again. These emails can take a minute or two to arrive, so be patient. On Thu, Feb 19, 2026 at 12:58 PM Heitor Peralles <[email protected]> wrote: > Can I stop receiving these emails? > I already unsubscribed... > > *Heitor G. Peralles* > *Direct**:* +55 21 979 661 187 <https://wa.me/5521979661187> > *Email:* [email protected] > *LinkedIn:* linkedin.com/in/heitorperalles > <https://www.linkedin.com/in/heitorperalles/> > > On Thu, Feb 19, 2026, 14:52 Gus Heck <[email protected]> wrote: > > > 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) > > > -- http://www.needhamsoftware.com (work) https://a.co/d/b2sZLD9 (my fantasy fiction book)
