Hi Shawn, Yeah, I understand that's the general logic but the recommendation in the above link is to avoid using *most* of the classes and supply a string representing the expression. A user seeing all these classes in the javadoc (or ide) would easily think that they should be using them.
After looking back at the 7.2 refguide I see that there used to be an example that explicitly set up names for classes, but that's now done automatically via o.a.s.streaming.Lang (yay for standardization! :) ), so there is no need to reference the vast majority of the streaming classes directly (unless ignoring Eric's advice in the linked post) This morning for fun I tested what it takes to move everything in the o.a.s.solrj.io package to core as a package names o.a.s.streaming, and only a few unit test configs got sticky. There were no cross refs to constants or uses by outside classes. I think things may have progressed to the point where stuff users shouldn't be using could be pulled down to core before they do get entangled in dependencies. Of course one can't just move everything, one has to leave behind something to facilitate the execution of streaming... but from the looks of the example here: https://lucene.apache.org/solr/guide/7_5/streaming-expressions.html this process needs only a zkhost, a collection and a string containing the expression, so it seems like the string should pass directly to a cloud solr client (which knows about a zkhost and collection already) and not require any special classes beyond the TupleStream return value and Tuple (produced by TupleStream)... plus Explanation and StreamComparator which are returned by other methods on TupleStream. -Gus On Sat, Oct 20, 2018, 2:39 PM Shawn Heisey <[email protected]> wrote: > On 10/20/2018 8:34 AM, Gus Heck wrote: > > To put it another way, I'm not sure why this statement from that > > article must be true: "SolrJ is what’s used for the communication > > between the Solr node, so this level must be exposed." > > All communication between Solr nodes uses SolrJ. SolrJ is an integral > part of the server as well as a jar providing a standalone client. > > Many of the string constants that Solr provides are actually located in > SolrJ, because they are useful for both client and server operations. > Take a look at the CommonParams class. > > Streaming expressions are something that users want to do with the > client, so it makes sense for some significant parts of it to live in > the client code. > > Thanks, > Shawn > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
