[
https://issues.apache.org/jira/browse/SOLR-11746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17018314#comment-17018314
]
Houston Putman commented on SOLR-11746:
---------------------------------------
I've been updating the patch with everything detailed above (docValues, norms,
and the specialized [* TO *] functionality for floats and doubles), as well as
extended tests.
I have run into a snag with the {{NormsFieldExistsQuery}}. For PointFields (not
TrieFields), the behavior of a field's {{SchemaField.indexOptions}} do not line
up with the {{FieldInfo.indexOptions}} for the same field. This means that when
[FieldInfo.hasNorms()|https://github.com/apache/lucene-solr/blob/master/lucene/core/src/java/org/apache/lucene/index/FieldInfo.java#L321]
is called in {{NormsFieldExistsQuery}}, for PointFields, *false* will be
returned even if the same logic {{(omitNorms == false && IndexOptions !=
IndexOptions.None)}} used with the data in {{SchemaField}} returns *true*.
Since this "hasNorms" logic is different in {{FieldType}}, which uses
SchemaType, and {{NormsFieldExistsQuery}}, which uses {{FieldInfo}}, the logic
in FieldType cannot accurately determine if the NormsFieldExistsQuery is the
correct method to use.
I've been unable so far to figure out how FieldInfo and SchemaField have
received different values for IndexOptions. (This seems to be the reason why
the logic results in different results, {{omitNorms}} has the correct value in
both classes.) Any advice here beyond just omitting the
{{NormsFieldExistsQuery}} entirely?
To be clear this issue only exists for PointFields.
> 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
>
>
> 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
