[
https://issues.apache.org/jira/browse/SOLR-11042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Kudryavtsev updated SOLR-11042:
--------------------------------------
Attachment: SOLR-11042.patch
> 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
> Security Level: Public(Default Security Level. Issues are Public)
> 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 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 patch attached) ? WDYT?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
