[
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
