SOLR-13309: Introduce LongRangeField to expose Lucene 'LongRange'#4192
Open
gerlowskija wants to merge 11 commits intoapache:mainfrom
Open
SOLR-13309: Introduce LongRangeField to expose Lucene 'LongRange'#4192gerlowskija wants to merge 11 commits intoapache:mainfrom
gerlowskija wants to merge 11 commits intoapache:mainfrom
Conversation
Introduces AbstractNumericRangeField as a shared base for numeric range field types (IntRangeField, and the forthcoming LongRangeField). The abstract class holds all infrastructure that is identical between variants: the numDimensions configuration and validation, shared regex patterns, and the standard field lifecycle methods (init, createFields, write, getSortField, getUninversionType, toInternal, toExternal, toNativeType). IntRangeField is reduced to int-specific logic only. The NumericRangeValue marker interface is introduced so that toNativeType() can recognise already-parsed range values without knowing the concrete subtype; concrete RangeValue classes implement it and override parseRangeValue() with a covariant return type so internal callers receive the fully-typed value without casting. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…icRangeQParserPlugin Introduces LongRangeField backed by Lucene's LongRange, mirroring IntRangeField for 64-bit values. Supports 1–4 dimensions, the same [min TO max] value syntax, and the full set of range query semantics (intersects, within, contains, crosses). Renames IntRangeQParserPlugin to NumericRangeQParserPlugin (same NAME constant "numericRange", so no user-facing change). The plugin now handles both IntRangeField and LongRangeField, dispatching to IntRange or LongRange query factory methods based on the field type. QParserPlugin and QueryEqualityTest updated to reference the renamed class. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…range.xml Adds LongRangeFieldTest (unit tests mirroring IntRangeFieldTest) and LongRangeQParserPluginTest (integration tests covering all 4 query criteria, 1–4 dimensions, multi-valued fields, error cases, extreme values, and values outside int range). Renames schema-intrange.xml to schema-numericrange.xml and adds LongRangeField type and field definitions alongside the existing IntRangeField ones so both test classes share a single schema file. Updates IntRangeQParserPluginTest to reference the renamed schema and corrected error message text. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…ntTest/LongTest The old names (IntRangeQParserPluginTest, LongRangeQParserPluginTest) implied non-existent plugin classes. The new names make clear that both are testing NumericRangeQParserPlugin against int and long fields respectively. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Contributor
Author
|
Still needed:
EDIT - these should all be done. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
https://issues.apache.org/jira/browse/SOLR-13309
Description
We recently added a Solr field type "IntRangeField" to allow users to index and search integer ranges (e.g. prices, business hours, grade ranges). But not everything is an integer. Lucene has additional "range" types:
LongRange,DoubleRange, andFloatRange.This PR tackles exposing the first of these additional Lucene types (i.e.
LongRange) in Solr asLongRangeField. This is ideal for timestamp ranges or other things that may not fit in a standard integer.Solution
The approach taken in this PR mirrors that taken by the IntRangeField addition in #4141, and is able to reuse a lot of the foundation used by that PR. To summarize a few highlights:
AbstractNumericRangeFieldLongRangeField, is added to mirror the existingIntRangeField. LongRangeField has all of the same limitations (e.g. no docValues or uninversion support) as IntRangeField and looks very similar from that perspective.NumericRangeQParserPlugin. The same QParser can be used to handle either IntRangeField or LongRangeField field types. (And should be expandable to handle double and float in the future).LongRangeFieldTestandNumericRangeQParserPluginLongTest. (Existing "IntRangeField" query tests have been renamed asNumericRangeQParserPluginIntTest.)The IntRangeField and LongRangeField types still have a bit more duplication in them than I'd like - particularly the
getSpecializedRangeQueryimplementations each of those has. The structure of both methods is nearly identical but there's a lot of type-specific operations in there (parsing String->long|int, checking against Integer.MAX_VALUE or Long.MAX_VALUE, etc.) and it made trimming the duplication a little hairy. If anyone can see a good way to do it, let me know.I used "Claude Code" a good bit in some of the earlier refactoring-steps of this PR. I've reviewed all of the generated code myself, but I'd love an extra careful set of eyes from another reviewer if possible.
Tests
New tests in
LongRangeFieldTestandNumericQParserPluginLongTest.Checklist
Please review the following and check all that apply:
mainbranch../gradlew check.