[jira] [Commented] (SOLR-11746) numeric fields need better error handling for prefix/wildcard syntax -- consider uniform support for "foo:* == foo:[* TO *]"

["Tomoko Uchida (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SOLR-11746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17048257#comment-17048257 ] 

Tomoko Uchida commented on SOLR-11746:
--------------------------------------

It seems like the Ref Guide build is now failing due to the changes here.
{code:java}
solr-ref-guide $ ant build-site
...
build-site:
     [java] Relative link points at id that doesn't exist in dest: #differences-between-lucenes-classic-query-parser-and-solrs-standard-query-parser
     [java]  ... source: file:/mnt/hdd/repo/lucene-solr/solr/build/solr-ref-guide/html-site/the-standard-query-parser.html
     [java] Relative link points at id that doesn't exist in dest: the-standard-query-parser.html#differences-between-lucenes-classic-query-parser-and-solrs-standard-query-parser
     [java]  ... source: file:/mnt/hdd/repo/lucene-solr/solr/build/solr-ref-guide/html-site/common-query-parameters.html
     [java] Processed 2611 links (1932 relative) to 3477 anchors in 262 files
     [java] Total of 2 problems found

BUILD FAILED
/mnt/hdd/repo/lucene-solr/solr/solr-ref-guide/build.xml:251: Java returned: 255
{code}
The build works for me when I removed those two lines.
{code:java}
--- a/solr/solr-ref-guide/src/common-query-parameters.adoc
+++ b/solr/solr-ref-guide/src/common-query-parameters.adoc
@@ -102,7 +102,7 @@ fq=+popularity:[10 TO *] +section:0
 ----
 
 * The document sets from each filter query are cached independently. Thus, concerning the previous examples: use a single `fq` containing two mandatory clauses if those clauses appear together often, and use two separate `fq` parameters if they are relatively independent. (To learn about tuning cache sizes and making sure a filter cache actually exists, see <<the-well-configured-solr-instance.adoc#the-well-configured-solr-instance,The Well-Configured Solr Instance>>.)
-* It is also possible to use <<the-standard-query-parser.adoc#differences-between-lucenes-classic-query-parser-and-solrs-standard-query-parser,filter(condition) syntax>> inside the `fq` to cache clauses individually and - among other things - to achieve union of cached filter queries.
+// * It is also possible to use <<the-standard-query-parser.adoc#differences-between-lucenes-classic-query-parser-and-solrs-standard-query-parser,filter(condition) syntax>> inside the `fq` to cache clauses individually and - among other things - to achieve union of cached filter queries.

diff --git a/solr/solr-ref-guide/src/the-standard-query-parser.adoc b/solr/solr-ref-guide/src/the-standard-query-parser.adoc
index c572e503e5b..3a3cd7f958d 100644
--- a/solr/solr-ref-guide/src/the-standard-query-parser.adoc
+++ b/solr/solr-ref-guide/src/the-standard-query-parser.adoc
@@ -174,7 +174,7 @@ The brackets around a query determine its inclusiveness.
 * You can mix these types so one end of the range is inclusive and the other is exclusive. Here's an example: `count:{1 TO 10]`
 
 Wildcards, `*`, can also be used for either or both endpoints to specify an open-ended range query.
-This is a <<#differences-between-lucenes-classic-query-parser-and-solrs-standard-query-parser,divergence from Lucene's Classic Query Parser>>.
+// This is a <<#differences-between-lucenes-classic-query-parser-and-solrs-standard-query-parser,divergence from Lucene's Classic Query Parser>>.
{code}
I know nothing about this issue, just noticed the broken links when I updated the ref-guide on another issue...

> numeric fields need better error handling for prefix/wildcard syntax -- consider uniform support for "foo:* == foo:[* TO *]"
> ----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: SOLR-11746
>                 URL: https://issues.apache.org/jira/browse/SOLR-11746
>             Project: Solr
>          Issue Type: Bug
>    Affects Versions: 7.0
>            Reporter: Chris M. Hostetter
>            Assignee: Houston Putman
>            Priority: Major
>             Fix For: master (9.0), 8.5
>
>         Attachments: SOLR-11746.patch, SOLR-11746.patch, SOLR-11746.patch, SOLR-11746.patch, SOLR-11746.patch, SOLR-11746.patch, SOLR-11746.patch, SOLR-11746.patch, SOLR-11746.patch, SOLR-11746.patch, SOLR-11746.patch
>
>
> On the solr-user mailing list, Torsten Krah pointed out that with Trie numeric fields, query syntax such as {{foo_d:\*}} has been functionality equivilent to {{foo_d:\[\* TO \*]}} and asked why this was not also supported for Point based numeric fields.
> The fact that this type of syntax works (for {{indexed="true"}} Trie fields) appears to have been an (untested, undocumented) fluke of Trie fields given that they use indexed terms for the (encoded) numeric terms and inherit the default implementation of {{FieldType.getPrefixQuery}} which produces a prefix query against the {{""}} (empty string) term.  
> (Note that this syntax has aparently _*never*_ worked for Trie fields with {{indexed="false" docValues="true"}} )
> In general, we should assess the behavior users attempt a prefix/wildcard syntax query against numeric fields, as currently the behavior is largely non-sensical:  prefix/wildcard syntax frequently match no docs w/o any sort of error, and the aformentioned {{numeric_field:*}} behaves inconsistently between points/trie fields and between indexed/docValued trie fields.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org