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