Since when is Solr’s, venerable “lucene” query syntax legacy? I don’t imagine it would ever disappear.
On Tue, Aug 20, 2024 at 7:30 PM Geoffrey Slinker <geoffrey_slin...@yahoo.com.invalid> wrote: > I am very happy that a discussion is underway and that maybe in the end > there will be new ways to generate queries for end users. > > I am not in a position to speak for what is already “inside” Apache Solr. > > If I can help please let me know. > > Geoffrey > > > On Aug 20, 2024, at 4:49 PM, Uwe Schindler <u...@thetaphi.de> wrote: > > > > +1: Thanks for this writeup, Jan! > > > > Am 20.08.2024 um 22:49 schrieb Jan Høydahl: > >> Having written tons of Java client code for querying elasticsearch, one > thing I > >> appreciate with the various QueryBuilders is how closely they map to > the actual > >> Lucene Query objects being the end result. Also, they are nicely > composable, > >> and of course map almost 1:1 to ES JSON query dsl. > >> > >> So if we want to evolve SolrJ's ability to construct complex queries, > I'd propose > >> we couple the SolrJ builders to our JSON Query DSL and take the > opportunity to > >> evolving, fixing and documenting that DSL in the process. > >> > >> It would be a bonus if builders could output/serialize to > legacy-query-string > >> as an option, but supporting only legacy would be a strange design > choice. > >> > >> Jan > >> > >>> 20. aug. 2024 kl. 22:10 skrev Gus Heck <gus.h...@gmail.com>: > >>> > >>> Also if expressed as xml the lucene classes can be sent to solr (not > sure > >>> if we have a tool to express them as xml however) > >>> > >>> > https://solr.apache.org/guide/solr/latest/query-guide/other-parsers.html#xml-query-parser > >>> > >>> On Tue, Aug 20, 2024 at 1:11 PM Mike Drob <md...@apache.org> wrote: > >>> > >>>> At the risk of sounding ignorant, what is the advantage of this over > using > >>>> Lucene classes to programmatically build queries and then toString > those? > >>>> It's not a single class, but the lucene search package has always > seemed > >>>> pretty straightforward to me. > >>>> > >>>> > https://lucene.apache.org/core/9_7_0/core/org/apache/lucene/search/package-summary.html#query > >>>> > >>>> > https://lucene.apache.org/core/9_7_0/core/org/apache/lucene/search/Query.html > >>>> > >>>> If the goal is human readable query methods, I had previously done > some of > >>>> the work in the opposite direction (matching queries to descriptions > >>>> instead of descriptions to queries) in test framework's QueryMatcher, > might > >>>> be worth comparing against. > >>>> > >>>> > https://github.com/apache/solr/blob/main/solr/test-framework/src/java/org/apache/solr/util/QueryMatchers.java > >>>> > >>>> > >>>> > >>>> On Tue, Aug 20, 2024 at 11:07 AM David Smiley <dsmi...@apache.org> > wrote: > >>>> > >>>>> Let's bikeshed before you write code, okay? Otherwise you > potentially > >>>>> waste time and/or grow attached to sunk costs. > >>>>> > >>>>> Feedback: > >>>>> * avoid the word "term"; it already has Lucene definition and a Solr > >>>>> query parser but you're using it in a way that isn't either. I > >>>>> recommend simply for "fieldQuery" -- these queries target specific > >>>>> fields after all. > >>>>> * Can we avoid top level classes that the user must know about; > >>>>> instead having one class -- QueryBuilder (or named > QueryStringBuilder) > >>>>> with factory methods that are easily discoverable? Not a huge deal. > >>>>> * Instead of "Group", lets acknowledge these map to a BooleanQuery so > >>>>> I think "bool" in some way should be used instead. Some bool builder > >>>>> can then have must() should() filter() methods without needing an > >>>>> enum. > >>>>> * Can't import any Lucene things > >>>>> > >>>>> I'll add examples below of my feedback ideas. > >>>>> > >>>>> On Tue, Aug 20, 2024 at 11:04 AM Geoffrey Slinker > >>>>> <geoffrey_slin...@yahoo.com.invalid> wrote: > >>>>> > >>>>>> Instantiate a Term and set the values and call toString to get a > string > >>>>> that can be used in a Standard Solr Query. > >>>>>> Term term = new Term("pink panther").withBoost(1.5f); > >>>>>> term. toString() > >>>>>> > >>>>>> Output: "pink panther"^1.5 > >>>>>> > >>>>>> Term term = new Term("title", "pink panther").withBoost(1.5f); > >>>>>> term. toString() > >>>>>> > >>>>>> Output: title:"pink panther"^1.5 > >>>>> final QueryStringBuilder B = new QueryStringBuilder(potential > >>>>> options); // immutable > >>>>> B.field("title", "ping panther").withBoost(1.5f).toString(); > >>>>> > >>>>> > >>>>>> TermGroup group = new TermGroup().with(Occur. > >>>>> MUST).withBoost(1.4f); > >>>>>> group. addTerm(new Term("foo", "bar").withProximity(1)); > >>>>>> > >>>>>> String query = group. toString(); > >>>>>> > >>>>>> Output: +( foo:bar~1 )^1.4 > >>>>> the outer MUST is pointless but I'll recreate anyway: > >>>>> > >>>>> final QueryStringBuilder B = new QueryStringBuilder(potential > >>>>> options); // immutable > >>>>> B.bool().must(B.fieldFuzzy("foo", "bar", > 1).withBoost(1.4)).toString(); > >>>>> > >>>>>> Example: > >>>>>> TermGroup group = new TermGroup().withConstantScore(5.0f); > >>>>>> group. addTerm(new Term("foo", "bar").withProximity(1)); > >>>>>> > >>>>>> String query = group. toString(); > >>>>>> > >>>>>> Output: ( foo:bar~1 )^=5 > >>>>> final QueryStringBuilder B = new QueryStringBuilder(potential > >>>>> options); // immutable > >>>>> B.fieldFuzzy("foo", "bar", 1).withConstantScore(5.0f).toString(); > >>>>> // no "group" terminology necessary > >>>>> > >>>>>> Instead of using string manipulation to create complex query strings > >>>> the > >>>>> TermGroup allows complex queries to be built inside an object model > that > >>>>> can be more easily changed. > >>>>>> If you need to generate a query like this: > >>>>>> +( > >>>>>> ( > >>>>>> title:"Grand Illusion"~1 > >>>>>> title:"Paradise Theatre"~1 > >>>>>> )^0.3 > >>>>>> ( > >>>>>> title:"Night At The Opera"~1 > >>>>>> title:"News Of The World"~1 > >>>>>> )^0.3 > >>>>>> ( > >>>>>> title:"Van Halen"~1 > >>>>>> title:1984~1 > >>>>>> )^0.3 > >>>>>> ) > >>>>>> > >>>>>> > >>>>>> The code to do so is as simple this: > >>>>>> > >>>>>> TermGroup group = new TermGroup().with(Occur. MUST); > >>>>>> > >>>>>> TermGroup favoriteStyx = group. addGroup().withBoost(0.3f); > >>>>>> TermGroup favoriteQueen = group. addGroup().withBoost(0.3f); > >>>>>> TermGroup favoriteVanHalen = group. addGroup().withBoost(0.3f); > >>>>>> > >>>>>> favoriteStyx. addTerm(new Term("title","Grand > >>>>> Illusion").with(Occur. SHOULD).withProximity(1)); > >>>>>> favoriteStyx. addTerm(new Term("title","Paradise > >>>>> Theatre").with(Occur. SHOULD).withProximity(1)); > >>>>>> favoriteQueen. addTerm(new Term("title","Night At The > >>>>> Opera").with(Occur. SHOULD).withProximity(1)); > >>>>>> favoriteQueen. addTerm(new Term("title","News Of The > >>>>> World").with(Occur. SHOULD).withProximity(1)); > >>>>>> favoriteVanHalen. addTerm(new Term("title","Van > >>>>> Halen").with(Occur. SHOULD).withProximity(1)); > >>>>>> favoriteVanHalen. addTerm(new Term("title","1984").with(Occur. > >>>>> SHOULD).withProximity(1)); > >>>>> // again, the outer bool MUST is pointless but will recreate your > example > >>>>> > >>>>> final QueryStringBuilder B = new QueryStringBuilder(potential > >>>>> options); // immutable > >>>>> > >>>>> var favoriteStyx = B.bool(); > >>>>> favoriteStyx.should(B.field("title", "Grand > Illusion").withProximity(1)); > >>>>> favoriteStyx.should(B.field("title", "Paradise > >>>> Theater").withProximity(1)); > >>>>> var favoriteQueen = B.bool(); > >>>>> favoriteQueen.should(B.field("title", "Night At The > >>>>> Opera").withProximity(1)); > >>>>> favoriteQueen.should(B.field("title", "News Of The > >>>>> World").withProximity(1)); > >>>>> > >>>>> var favoriteVanHalen = B.bool(); > >>>>> favoriteVanHalen.should(B.field("title", "Van > Halen").withProximity(1)); > >>>>> favoriteVanHalen.should(B.field("title", "1984").withProximity(1)); > >>>>> > >>>>> B.bool().must( // pointless wrap > >>>>> B.bool().should(favoriteStyx.withBoost(0.3f)) > >>>>> .should(favoriteQueen.withBoost(0.3f)) > >>>>> .should(favoriteVanHalen.withBoost(0.3f)) > >>>>> ).toString(); > >>>>> > >>>>> --- > >>>>> If we imagine plausibly expanding support to write Solr JSON as an > >>>>> alternative, then it could affect the code choices. Like > >>>>> toSolrLuceneSyntax() and toSolrQueryDsl(). > >>>>> > >>>>> --------------------------------------------------------------------- > >>>>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > >>>>> For additional commands, e-mail: dev-h...@solr.apache.org > >>>>> > >>>>> > >>> > >>> -- > >>> http://www.needhamsoftware.com (work) > >>> https://a.co/d/b2sZLD9 (my fantasy fiction book) > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > >> For additional commands, e-mail: dev-h...@solr.apache.org > >> > > -- > > Uwe Schindler > > Achterdiek 19, D-28357 Bremen > > https://www.thetaphi.de > > eMail: u...@thetaphi.de > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > > For additional commands, e-mail: dev-h...@solr.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > >
