CoreSolrClient - Emphasizes it works with a single core/collection, and it is also the core of the other clients DirectSolrClient - Direct endpoint access
Jan > 6. nov. 2025 kl. 21:48 skrev David Smiley <[email protected]>: > > Let's remove it. Well, I mean, not add it back :-) > > On Thu, Nov 6, 2025 at 3:19 PM Jason Gerlowski <[email protected]> > wrote: > >>> I'm lukewarm with "SimpleSolrClient" >> >> Fair enough - it's just there by way of example. If we agreed that the >> "Http"-prefix was worth reconsidering, I'm sure the group could arrive >> at *something* we like better. >> >>> I think HttpSolrClient is a fine name too, >> >> I guess that's where I'm lost. What do you like about the prefix? >> Are there benefits or things you like about it beyond the fact that it >> has inertia? >> >> To my mind it conveys 0 bits of information. But maybe I'm missing >> something... >> >> On Thu, Nov 6, 2025 at 1:59 PM David Smiley <[email protected]> wrote: >>> >>> I'm lukewarm with "SimpleSolrClient". I like that it conveys no >> additional >>> value-add like SolrCloud awareness or load-balancing. However the JDK & >>> Jetty impls have some sophistication to their implementations, like >> async. >>> I think HttpSolrClient is a fine name too, plus users and LLMs have >> already >>> become quite aware of it ;-). I don't think it implies a lack of SSL >>> support. >>> >>> My only concern with bringing HttpSolrClient back (or adding >>> SimpleSolrClient) is that it doesn't _really_ need to exist as a base >>> abstraction. In my PR, it just exposes a URL getter. So what; the >> caller >>> probably should have no need to call that any way. It can be nice in a >>> test that wants to manually then use an HttpClient, but it could just as >>> well have gotten that URL from Jetty test infra. >>> >>> On Thu, Nov 6, 2025 at 10:17 AM Jason Gerlowski <[email protected]> >>> wrote: >>> >>>> I was re-reading this thread in preparation to review the PR David >>>> mentioned above, and had an interesting thought that hadn't struck me >>>> on previous readings. I hate to bring in new ideas at the "11th >>>> hour", but I'd also hate to leave it unsaid in case folks think >>>> there's something there. So, with my apologies, here goes. Feel free >>>> to ignore: >>>> >>>>> an LLM that knows about >>>>> HttpSolrClient's pervasiveness. And who can blame any person or >> LLM >>>> for >>>>> using such an obvious name like that. What a great name! >>>> >>>> ... >>>> >>>>> "HttpSolrClient" (a great-name) >>>> >>>> ... >>>> >>>>> the desirable class name "HttpSolrClient" >>>> >>>> HttpSolrClient is a much better name to expose to folks than many of >>>> the current options (Http2SolrClient, HttpJdkSolrClient, etc.), which >>>> I think is mostly what David was trying to convey in those quotes >>>> above. But is it *really* desirable in a general sense? >>>> >>>> The "Http-" prefix was (AFAICT) chosen at a time when it was necessary >>>> to distinguish these clients from "EmbeddedSolrServer" (which relied >>>> on a local SolrCore and didn't send any network traffic). But 10+ >>>> years on from that decision the "Http" signifier makes much less sense >>>> IMO. >>>> >>>> Today, the common-thread running through our "Http" SolrClients is >>>> that (1) they use a single base URL and (2) don't layer on any of the >>>> additional logic found in other implementations. At best, the "Http" >>>> signifier is disconnected from that commonality and does nothing to >>>> convey it. At worst, it's actively misleading: "Oh, I guess these are >>>> the only clients that use HTTP then", "Oh, I guess it only supports >>>> HTTP and not HTTPS" >>>> >>>> It'd be a bigger departure, but while we're renaming the clients is it >>>> worth considering something without the "Http" prefix altogether? Say, >>>> "SingleUrlSolrClient" or "SimpleSolrClient" or something along those >>>> lines? >>>> >>>> Apologies again for bringing this up, and so late at that. >>>> >>>> Best, >>>> >>>> Jason >>>> >>>> >>>> On Sun, Nov 2, 2025 at 4:39 PM David Smiley <[email protected]> >> wrote: >>>>> >>>>> Some progress: https://github.com/apache/solr/pull/3829 >>>>> >>>>> I think the org.apache.solr.client.solrj package should be used for >> not >>>>> only SolrClient (it's there now) but for HttpSolrClient (now that >> it's >>>>> abstract & simple), but also CloudSolrClient. It's debatable what >>>> belongs >>>>> in "impl"; I don't love that package name TBH. But the classes >>>>> in org.apache.solr.client.solrj should be chosen conservatively >> since we >>>>> have a rich set of sub-packages to organize most things. Thus >> *only* the >>>>> most foundational things that otherwise have no obvious home belong >> in >>>>> org.apache.solr.client.solrj. >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
