My recollection from working on this code years ago is that other definitions of "equal" can be supported by creating new implementations of the Equalitor class ( https://github.com/apache/solr/blob/main/solr/solrj/src/java/org/apache/solr/client/solrj/io/eq/Equalitor.java#L27-L30). The purpose of the Equalitor class is not so much to say "these two values are the same" but instead "these values can be joined on". Joins were one of the first streaming expressions created and as such existed before evaluators. The Equalitor class is a bit of an unfortunate holdover from that initial implementation. Were I doing it again now I'd use evaluators instead.
That said, it may be possible to refactor the Equalitor class as a type of Evaluator. An approach like that would, I think, clean up what's become a confusing holdover of that original implementation and simultaneously make it possible to use any evaluator within a join clause. Alternatively, it'd be possible to enhance the join classes to support either Equalitors or Evaluators. Equalitors are constructed with this method - https://github.com/apache/solr/blob/main/solr/solrj/src/java/org/apache/solr/client/solrj/io/stream/expr/StreamFactory.java#L352 - so you could enhance any place that's called from to also support Evaluators. Cheers, Dennis On Tue, Jan 4, 2022 at 5:00 PM Damiano Albani <damiano.alb...@gmail.com> wrote: > Hello, > > It's the first time that I hear about those Lucene expressions written in > JavaScript. Good to learn about it! > I suppose you're referring to > > https://lucene.apache.org/core/9_0_0/expressions/org/apache/lucene/expressions/js/package-summary.html > ? > I couldn't find much information about how to use it, especially in > combination with Solr. If someone knowledgeable could chime in, that would > be great. > Though what I see on the API documentation page at first impression, is > that the list of supported functions is pretty limited. > Actually, I think that Solr's decorators provide a similar coverage of > functions out of the box: > https://solr.apache.org/guide/8_11/stream-evaluator-reference.html. > If I can find some time, I will play with my java() decorator idea and see > if it is any good. > Especially in terms of performance, where JavaScript-in-Lucene could have > the upper hand indeed. > > Regards, > > On Tue, Jan 4, 2022 at 6:41 PM David Smiley <dsmi...@apache.org> wrote: > > > I'd prefer to use Lucene's "expressions" module and thus do JavaScript. > > This is more accessible to a wider audience, and I believe makes > > safety/security easier (though I have not checked). > > > > ~ David Smiley > > Apache Lucene/Solr Search Developer > > http://www.linkedin.com/in/davidwsmiley > > > > > > On Tue, Jan 4, 2022 at 12:30 PM Eric Pugh < > ep...@opensourceconnections.com > > > > > wrote: > > > > > That looks great! I love how (relatively) simple it all is to write > your > > > own logic. > > > > > > One of the reasons that we added packages (bin/solr package) to Solr is > > so > > > that if someone wants to add something like a java() evaluator, they > can! > > > > > > > On Jan 4, 2022, at 11:40 AM, Damiano Albani < > damiano.alb...@gmail.com> > > > wrote: > > > > > > > > Hi, > > > > > > > > Just a quick note to mention that I've managed to implement what I > > wanted > > > > in terms of non equi-joins. > > > > Should someone be interested, I've put my code on > > > > https://github.com/dalbani/solr-streaming-expressions. > > > > > > > > By the way, I happened to need a startsWith function and I > implemented > > it > > > > quite easily. > > > > But I'm wondering if a very generic -- if not possibly not very safe > -- > > > > java() evaluator could be built. > > > > That would open streaming expressions to the whole Java API instead > of > > > > having to write individual evaluators. > > > > For the example of startsWith, it could look like something in the > > range > > > of: > > > > > > > >> java(val(Hello), val(World), "arg0.startsWith(arg1)") > > > > > > > > Using say, https://www.javassist.org/, to turn the code argument > into > > > > bytecode. > > > > What do you think? > > > > > > > > Regards, > > > > > > > > On Wed, Dec 29, 2021 at 12:39 PM Damiano Albani < > > > damiano.alb...@gmail.com> > > > > wrote: > > > > > > > >> Hello, > > > >> > > > >> I'm new to streaming expressions, so I'm trying to understand their > > > >> features and limitations. > > > >> In particular the so-called "stream operators" implementing join > > > >> operations. > > > >> Like "innerJoin", "leftOuterJoin", etc. > > > >> > > > >> I see that they support a "on" parameter, defining the *equality* > > check > > > >> to be performed. > > > >> But, coming from the SQL world, I'm used to being able to use a > > variety > > > of > > > >> comparison operators in join predicates. That is, not only equality, > > as > > > in > > > >> "equi-joins". > > > >> > > > >> Is there a reason why the current implementation of Solr supports > > > >> equi-joins only? Would it be technically possible (and desired) to > > > support > > > >> other comparison operators with joins? > > > >> And maybe somehow allow the use of the available stream evaluators > > > >> <https://solr.apache.org/guide/8_11/stream-evaluator-reference.html > >? > > > >> > > > >> To give the context of my question: I'm trying to join 2 sets of > > > documents > > > >> with a hierarchical relationship. > > > >> My goal is to join them using a "path" field on one side and > > > >> "descendent_path" field on the other side. > > > >> But it looks like that only doc values are accessible (and not > > analyzed > > > >> ones) in streams, so I suppose I'd be left with a join criteria like > > > this > > > >> pseudo-code: > > > >> > > > >>> on="starts_with(right.path, left.path)" > > > >> > > > >> Where, in this hypothetical example: > > > >> > > > >>> left.path=/categories/category1" > > > >>> right.path=/categories/category1/sub-categories/sub-category-a" > > > >> > > > >> > > > >> Or do I completely misunderstand how Solr (streams) work? ;-) > > > >> Thanks for your help! > > > >> > > > >> Regards, > > > >> > > > >> -- > > > >> Damiano Albani > > > >> > > > > > > > > > > > > -- > > > > Damiano Albani > > > > > > _______________________ > > > Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 > | > > > http://www.opensourceconnections.com < > > > http://www.opensourceconnections.com/> | My Free/Busy < > > > http://tinyurl.com/eric-cal> > > > Co-Author: Apache Solr Enterprise Search Server, 3rd Ed < > > > > > > https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw > > > > > > > > > This e-mail and all contents, including attachments, is considered to > be > > > Company Confidential unless explicitly stated otherwise, regardless of > > > whether attachments are marked as such. > > > > > > > > > > > -- > Damiano Albani >
