> > query could be extended to something like Title:(word1 for word2) > OR Abstract:(word3) which I do not know how to express it via qf
how would you like your pf to work with this? What is the final query you aim to? Probably in your case it would be better to fully go "custom" and write your query instead of realying on the pf parameter. I suspect pf was born in the dismax (where just free text query is supposed to be in the input) I doubt it is compatible at all with Lucene syntax in the main query (which is supported by the edismax). Cheers -------------------------- Alessandro Benedetti Apache Lucene/Solr Committer Director, R&D Software Engineer, Search Consultant www.sease.io On Tue, 11 May 2021 at 10:28, Thomas Karampelas <tkarampe...@atypon.com> wrote: > Bumping this in case someone that has any idea missed it. > > On Wed, Mar 31, 2021 at 11:14 AM Thomas Karampelas <tkarampe...@atypon.com > > > wrote: > > > Hi, > > > > I run solr 8.4.1 and I issue the following query on edismax parser: > > *defType=edismax&q=Title:(word1 for word2) &pf=Title&q.op=AND* > > > > The parsed query edismax comes out with is the following: > > +( > > +( > > +(+Title:word1 +Title_en:word2))) > > (+(Title:\"for word2\")) > > > > Firstly, I expected the strange multiple MUST operators since I have read > > they are added when using AND as a default op. Also, in the first main > > clause the *for *term is missing correctly, since I have a stopword > > filtering in my analysis chain. > > However, what puzzles me is the fact that pf is skipping the first word > > of my query. This won't happen if I was to add spaces after the opening > and > > before the closing parenthesis like that *Title:( word1 for word2 )*. > > > > I took a look at the code and found why it did this (it seems that pf > > ignores the first part (*(word1*) because it ignores clauses assigned to > > fields, inside > > org.apache.solr.search.ExtendedDismaxQParser#addPhraseFieldQueries and > the > > first part has Title as its field but the others do not), but I cannot > > really understand the reasoning behind it. Is this to be expected or is > > this a bug? > > > > I know that I could use the qf parameter to target the field directly, > but > > the above query could be extended to something like Title:(word1 for > word2) > > OR Abstract:(word3) which I do not know how to express it via qf. Also I > > expected such syntax to work as an alternative in any case. > > > > Thanks, > > Thomas > > >
