[
https://issues.apache.org/jira/browse/SOLR-11042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17106133#comment-17106133
]
Pieter commented on SOLR-11042:
-------------------------------
I like to relate this issue to SOLR-6203: In the scenario above Solr parses a
sort clause by first trying to interpret it as a function query and if that
fails, does a schema lookup (where the match-all dynamic field results in a
field match). When doing a (multi-sharded) grouped query (that's the SOLR-6203
scenario) Solr does it the other way around, first doing a schema lookup (which
results in an exception if the type of that field does not match the type of
the function result). Basically both approaches try to address the same problem
(I think); Solr doesn't really know if a sort clause is a field name of
function, it just figures it out by trying and see what sticks.
A solution could be to add some extra (optional) syntax to sort clauses, so
Solr doesn't have to guess, for example;
{code:java}
&sort=func:query($sortQuery) asc, score desc, fld:id desc
{code}
Still, what worries me a bit a bit, and what triggered me to write this
comment, is that different pieces of code in Solr try to solve the same problem
in different ways.
> Sort by function query: throw exception if can't parse
> ------------------------------------------------------
>
> Key: SOLR-11042
> URL: https://issues.apache.org/jira/browse/SOLR-11042
> Project: Solr
> Issue Type: Improvement
> Affects Versions: 7.0
> Reporter: Andrey Kudryavtsev
> Priority: Minor
> Labels: patch
> Attachments: SOLR-11042.patch
>
>
> I have a couple of use cases where I need to sort result list by function
> query values (something like {{sort query(..) desc}} or {{sort product(...)
> asc}} )
> Even if that {{...}} could be a pretty complicated query with lots of
> clauses, this technique worked like a charm until I created a query in
> incorrect Solr's syntax , i.e. I created a string which {{FunctionQParser}}
> failed to parse ( I had something that in simplification could be described
> as {{sort=query($sortQuery) desc&sortQuery=type: a b c}} without proper
> {{df}} ).
> This lead to unexpected behaviour (at least from my pov). See
> [SortSpecParsing#parseSortSpecImpl|https://github.com/apache/lucene-solr/blob/e2521b2a8baabdaf43b92192588f51e042d21e97/solr/core/src/java/org/apache/solr/search/SortSpecParsing.java#L88]
> :
> * FunctionQParser failed to parse query, but exception wasn't thrown:
> {code}
> catch (Exception e) {
> // hang onto this in case the string isn't a full field name
> either
> qParserException = e;;
> }
> {code}
> * Solr tried to handle sorting clause as a field and made a lookup into
> Schema:
> {code}
> SchemaField sf = schema.getFieldOrNull(field);
> if (null == sf) {
> ......
> {code}
> * I had a "match all" field type mapped on {{*}} in schema, and this type
> was matched by string {{query($sortQuery)}}
> * Then there are two possibilities (and I don't like both of them):
> ** If "match all" field type is multi valued, there would be an exception
> {code}
> can not sort on multivalued field: query($sortQuery)
> {code}
> ** If "match all" field type is single valued, then it would try to sort by
> values for +field+ {{query($sortQuery)}} (without any exceptions)
> I understand (by tests running) from where this error hiding came from.
> But what if we will make some basic efforts to help guys like me to detect
> errors in syntax as soon as possible (see [^SOLR-11042.patch]) ? WDYT?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
