I don’t remember the detailed any longer, but Tim Potter worked on this problem a few years back and ran into lots of thorns, especially with cluster upgrades. I’d look at the discussions from that project for insight into your current questions.
Mike On Sun, Mar 29, 2026 at 5:32 AM Christos Malliaridis < [email protected]> wrote: > I see this pattern often, and I also kind of wish it would be better-typed. > When I am usually migrating code to use URI / URL, I often end up facing > issues with serialization, which is probably the main reason String is > preferred. > > But the benefits of using a type like URL when passing a node name around > is likely more convenient in many ways, especially the error handling that > can be avoided to some degree. > > However, what is the impact of following that route at least for internal > code? And since we are storing data into files, what about the > serialization and deserialization of that URI? I believe it should not be > much of a problem anyway? > > Christos > > On Sat, Mar 28, 2026 at 7:45 PM David Smiley <[email protected]> wrote: > > > Internally, SolrCloud distinguishes nodes by a partial URL like > > "localhost:8983/solr" (off the top of my head). Yet to actually > > communicate with such a node, you need to apply the URL scheme -- > > "http://"; or "https://";. Is this serving us well? It seems annoying > > to always have to translate and furthermore to not hold references > > using a better type like java.net.URI instead of String, which is > > basically untyped. Admittedly I haven't had to experience a URL > > scheme change... and I don't know if that's even possible with Solr > > today. > > > > ~ David Smiley > > Apache Lucene/Solr Search Developer > > http://www.linkedin.com/in/davidwsmiley > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > >
