[
https://issues.apache.org/jira/browse/SOLR-11746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17018406#comment-17018406
]
Chris M. Hostetter commented on SOLR-11746:
-------------------------------------------
[~houston] - i have to step away for a minute, but based on my poking around a
bit i think that fundamentally the problem is that – at a lucene level – Point
fields just don't seem to ever support (or care about) norms?
Unlike other solr fieldtypes, none of the {{...solr.schema.*PointField}} impls
ever _create_ or pass a {{...lucene.document.FieldType}} instance (containing
the "omitNorms" setting from the SchemaField) to the underlying
{{...lucene.document.Field}} instance that they create their
{{...solr.schema.FieldType.createField()}} method – because the underlying
classes (like {{...lucene.document.IntPoint}} don't _allow_ you to specify
you're own FieldType (where you set things like {{omitNorms}} ... instead
that's all private & internal to the (point {{Field}} impl
----
There are no existing lucene layer test cases of using Point Fields +
NormsFieldExistsQuery, and I'm pretty sure if you tried to write one you'd find
that you can never make it pass, because it's physically impossible to create a
"Point" field with {{omitNorms=true}} ?
BUT ... I don't think this is a bug? ... If you look back at what Uwe said
above when he suggested using NormsFieldExistsQuery he was very specific...
{quote}If the field has norms enabled (e.g. a text field or StringField with
norms), then you can also use NormsFieldExistsQuery:
{quote}
...i think fundamentally your patch should be restructured to ensure it never
attempts to use NormsFieldExistsQuery with Point based fields?
Off the top of my head, i would straw man suggest eliminating the concept of
{{getSpecializedExistenceQuery}} and instead just make FieldType use...
{code:java}
public Query getExistenceQuery(QParser parser, SchemaField field) {
if (field.hasDocValues()) {
return new DocValuesFieldExistsQuery(field.getName());
} else if (!isPointField() && !field.omitNorms() && field.indexOptions() !=
IndexOptions.NONE) {
return new NormsFieldExistsQuery(field.getName());
}
// Default to an unbounded range query
return getRangeQuery(...); // ? getSpecializedRangeQuery ?
}
{code}
And let subclasses (like the point fields) override getExistenceQuery as needed.
(Although I generally hate the existence of that {{isPointField()}} method, so
i'm not fully sold on this idea ... I'm also not really clear on the
purpose/need of getSpecializedRangeQuery as opposed to just letting subclasses
override {{getRangeQuery(...)}} ... so take this entire suggestion with a grain
of salt)
> 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
>
>
> 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: [email protected]
For additional commands, e-mail: [email protected]
