Skip to content

SOLR-13309: Introduce LongRangeField to expose Lucene 'LongRange'#4192

Open
gerlowskija wants to merge 11 commits intoapache:mainfrom
gerlowskija:SOLR-13309-long-range-field
Open

SOLR-13309: Introduce LongRangeField to expose Lucene 'LongRange'#4192
gerlowskija wants to merge 11 commits intoapache:mainfrom
gerlowskija:SOLR-13309-long-range-field

Conversation

@gerlowskija
Copy link
Contributor

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, and FloatRange.

This PR tackles exposing the first of these additional Lucene types (i.e. LongRange) in Solr as LongRangeField. 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:

  1. Common functionality for all range fields is extracted from the existing IntRangeField and moved into AbstractNumericRangeField
  2. A new field type, LongRangeField, is added to mirror the existing IntRangeField. LongRangeField has all of the same limitations (e.g. no docValues or uninversion support) as IntRangeField and looks very similar from that perspective.
  3. The IntRangeQParserPlugin has been renamed and generalized as 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).
  4. New tests for long support have been added in LongRangeFieldTest and NumericRangeQParserPluginLongTest. (Existing "IntRangeField" query tests have been renamed as NumericRangeQParserPluginIntTest.)

The IntRangeField and LongRangeField types still have a bit more duplication in them than I'd like - particularly the getSpecializedRangeQuery implementations 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 LongRangeFieldTest and NumericQParserPluginLongTest.

Checklist

Please review the following and check all that apply:

  • I have reviewed the guidelines for How to Contribute and my code conforms to the standards described there to the best of my ability.
  • I have created a Jira issue and added the issue ID to my pull request title.
  • I have given Solr maintainers access to contribute to my PR branch. (optional but recommended, not available for branches on forks living under an organisation)
  • I have developed this patch against the main branch.
  • I have run ./gradlew check.
  • I have added tests for my changes.
  • I have added documentation for the Reference Guide
  • I have added a changelog entry for my change

gerlowskija and others added 7 commits March 5, 2026 15:57
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>
@gerlowskija
Copy link
Contributor Author

gerlowskija commented Mar 6, 2026

Still needed:

  • changelog entry
  • ref guide doc updates
  • look into refactoring the type-specific elements in NumericRangeQParserPlugin

EDIT - these should all be done.

@github-actions github-actions bot added the documentation Improvements or additions to documentation label Mar 6, 2026
@gerlowskija gerlowskija marked this pull request as ready for review March 6, 2026 17:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

cat:schema cat:search documentation Improvements or additions to documentation tests

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant