[
https://issues.apache.org/jira/browse/SOLR-11746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17021403#comment-17021403
]
Chris M. Hostetter commented on SOLR-11746:
-------------------------------------------
Skimmed the patch, read the tests – LGTM.
{quote}I've also increased the documentation to make all of this explicitly
clear. I'm very open to suggestions on how the documentation could be improved.
{quote}
I think the best way to document this would be along the lines of what i wrote
before...
{quote} * {{foo:*}} matches any document that has a value in that field
* {{foo:[* TO *]}} matches any document with a value between the effective
values of -Infinity and +Infinity for that field type{quote}
Then as an {{NOTE}} box we can mention: "For many field types, {{foo:[* TO *]}}
is functionally equivalent to {{foo:*}}, but the notable exception is
float/double types that support {{NaN}}. {{NaN}} will be matched by {{foo:*}}
but is not in the range of {{foo:[* TO *]}}"
I would also suggest moving the docs about {{foo:*}} / existences queries
_before_ the docs about range queries, to better facilitate this explanation of
the distinction
----
Ideally we should also be able to add something like this to QueryEqualityTest,
to _prove_ the docs are correct, ..
{noformat}
public void testQueryLuceneFloatNumericRangeInfinity() throws Exception {
for (String field : Arrays.asList("foo_f", "foo_f_dvo",
"foo_d", "foo_d_dvo")) {
assertQueryEquals("lucene", field+":[* TO *]", field+":[-Infinity TO
Infinity]");
}
}
{noformat}
...but when i tried beasting that it seemed to fail on Trie Float (and
presumably TrieDouble) ?
(Off the top of my head I'm not sure why it's failing – it doesn't seem to be
a regression in your changes though, so feel free to punt this into a new
'Optimization' jira if nothing immediately jumps out at you... it shouldn't
have any practical impacts on anyone except slightly better cache hit ratios
for (non existent) people who might try both syntaxes on the same field)
> 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
>
>
> 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
