Major Description
In getting caught up with the new PointsField work in SOLR-8396 & SOLR-9987 I realized:
- There's some inconsistencies/contridictions in how the new field types implement FieldType.getUninversionType vs some of the error handling added to methods like SchemaField.checkSortability.
- as part of
SOLR-9987, SORTED_foo constants were added to UninvertingReader and used in the getUninversionType methods for PointFields – even though those constants are useless (because UninvertingReader doesn't support uninverting multivalued points: SOLR-9202) - the changes made to methods like SchemaField.checkSortability to explicitly check isPointsField should have never been needed if those methods were paying attention to getUninversionType – but those types of checks weren't added when getUninversionType was introduced (the existing checks pre-date the DocValues API, back where any single-valued indexed field was implicitily "uninvertable")
- If all of the above is corrected, the only thing preventing UninvertedReader from working properly with Solr's new PointField types (in the single valued case) is a trivial bug in IndexSchema (being presumptutious about what is uninvertable)
I'm opening this issue to track fixing all of this, such that the end result will be:
- single valued PointFields will be uninvertable (ie: sortable even if they don't have docvalues)
- error handling code will be simplified
- unused/unsupported/misleading constants in UninvertingReader will be removed.
Attachments
Attachments
Issue Links
- is related to
-
SOLR-10872 _version_ returns exception when changed to point field
-
- Open
-