I have just tried this with 9.4.1, and I can confirm that it works as intended. Thanks for fixing, much appreciated!
Best regards, /Noah -- Noah Torp-Smith (n...@dbc.dk) ________________________________ Fra: Noah Torp-Smith <n...@dbc.dk.INVALID> Sendt: 25. oktober 2023 09:59 Til: users@solr.apache.org <users@solr.apache.org> Emne: Sv: issue with f.<fieldname>.qf in solr 9.4 Just for clarification: this works in 9.3 (like 9.1.1), and not 9.4. Thanks for reacting to this, I appreciate it. I'll keep an eye on SOLR-16916. Regards, /Noah -- Noah Torp-Smith (n...@dbc.dk) ________________________________ Fra: Chris Hostetter <hossman_luc...@fucit.org> Sendt: 24. oktober 2023 19:32 Til: users@solr.apache.org <users@solr.apache.org> Emne: Re: issue with f.<fieldname>.qf in solr 9.4 (thank you for using an example query that works against the techproducts example! .. makes it very easy to reproduce) At the *qparser* level, what you are doing is still working in 9.4.. hossman@slate:~/lucene/solr [j11] [tags/releases/solr/9.4.0] $ curl -sS 'http://localhost:8983/solr/techproducts/select?omitHeader=true&fl=id&defType=edismax&q=all:belkin&f.all.qf=compName_s+id+address_s' { "response":{ "numFound":1, "start":0, "numFoundExact":true, "docs":[{ "id":"belkin" }] } } ...the error you are getting only seems to happen when using the JSON Request API. (as in your email) Below is the ERROR log w/stacktrace that i get when i try your request (FWIW: including solr error log messages in email questions about request errors is always a great way to help devs answer your questions) The main thing that jumps out at me is that the edismax parser isn't involved -- it appears to have decided the LuceneQParser should be used? Which makes me speculate that something broke in how the "params block" is parsed when using the JSON Request API? Skimming CHANGES.txt looking for mentions of JSON Request API changes led me to this... * SOLR-16916: Use of the JSON Query DSL should ignore the defType parameter (Christina Chortaria, Max Kadel, Ryan Laddusaw, Jane Sandberg, David Smiley) ...i'm having a hard time wrapping my head around the jira comments ... the CHANGES.txt entry is written like the point of the issue was to intentionally 'ignore' defType in the JSON Query API, but the comments in the Jira read like using 'defType' was broken in 7.2 and this issue "fixed" it so it would work again starting in 9.4? ... the commit itself only shows testing what happens if 'defType=edismax' is defined as a request handler default. I'm not really sure what's going on here or what the intent was ... i've posted a comment in the jira... https://issues.apache.org/jira/browse/SOLR-16916 2023-10-24 16:57:07.705 ERROR (qtp1535026957-24) [ x:techproducts t:localhost-24] o.a.s.h.RequestHandlerBase Client exception => org.apache.solr.common.SolrException: undefined field all at org.apache.solr.schema.IndexSchema.getDynamicFieldType(IndexSchema.java:1478) org.apache.solr.common.SolrException: undefined field all at org.apache.solr.schema.IndexSchema.getDynamicFieldType(IndexSchema.java:1478) ~[?:?] at org.apache.solr.schema.IndexSchema$SolrQueryAnalyzer.getWrappedAnalyzer(IndexSchema.java:500) ~[?:?] at org.apache.lucene.analysis.DelegatingAnalyzerWrapper$DelegatingReuseStrategy.getReusableComponents(DelegatingAnalyzerWrapper.java:83) ~[?:?] at org.apache.lucene.analysis.Analyzer.tokenStream(Analyzer.java:184) ~[?:?] at org.apache.lucene.util.QueryBuilder.createFieldQuery(QueryBuilder.java:256) ~[?:?] at org.apache.solr.parser.SolrQueryParserBase.newFieldQuery(SolrQueryParserBase.java:527) ~[?:?] at org.apache.solr.parser.QueryParser.newFieldQuery(QueryParser.java:68) ~[?:?] at org.apache.solr.parser.SolrQueryParserBase.getFieldQuery(SolrQueryParserBase.java:1140) ~[?:?] at org.apache.solr.parser.SolrQueryParserBase.handleBareTokenQuery(SolrQueryParserBase.java:856) ~[?:?] at org.apache.solr.parser.QueryParser.Term(QueryParser.java:454) ~[?:?] at org.apache.solr.parser.QueryParser.Clause(QueryParser.java:293) ~[?:?] at org.apache.solr.parser.QueryParser.Query(QueryParser.java:173) ~[?:?] at org.apache.solr.parser.QueryParser.TopLevelQuery(QueryParser.java:143) ~[?:?] at org.apache.solr.parser.SolrQueryParserBase.parse(SolrQueryParserBase.java:274) ~[?:?] at org.apache.solr.search.LuceneQParser.parse(LuceneQParser.java:51) ~[?:?] at org.apache.solr.search.QParser.getQuery(QParser.java:188) ~[?:?] at org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:172) ~[?:?] at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:431) ~[?:?] at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:226) ~[?:?] at org.apache.solr.core.SolrCore.execute(SolrCore.java:2901) ~[?:?] : Date: Tue, 24 Oct 2023 12:01:20 +0000 : From: Noah Torp-Smith <n...@dbc.dk.invalid> : Reply-To: users@solr.apache.org : To: "users@solr.apache.org" <users@solr.apache.org> : Subject: issue with f.<fieldname>.qf in solr 9.4 : : Hello, : : When I spin up the techproducts example in solr 9.1.1, I am able to send this to the /query endpoint and get a reasonable response: : : { : "query": "+all:belkin", : "fields": "id compName_s", : "offset": 0, : "limit": 10, : "params": { : "defType": "edismax", : "f.all.qf": "id compName_s address_s" : } : } : : The point is that "all" then specifies a list of fields to look in, "all" is just a name, it could be anything. : : When I send the same to the /query endpoint in 9.4, I get a message stating that the "all" field does not exist. We use the f.<>.qf construction for a variety of things, so it'd be sad for us if that was discontinued. : : Is this a bug or intentional? : : Thanks, : : /Noah : : : : -- : : Noah Torp-Smith (n...@dbc.dk) : -Hoss http://www.lucidworks.com/
