gerlowskija opened a new pull request, #4192: URL: https://github.com/apache/solr/pull/4192
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: - [x] I have reviewed the guidelines for [How to Contribute](https://github.com/apache/solr/blob/main/CONTRIBUTING.md) and my code conforms to the standards described there to the best of my ability. - [x] I have created a Jira issue and added the issue ID to my pull request title. - [x] I have given Solr maintainers [access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) to contribute to my PR branch. (optional but recommended, not available for branches on forks living under an organisation) - [x] I have developed this patch against the `main` branch. - [ ] I have run `./gradlew check`. - [x] I have added tests for my changes. - [ ] I have added documentation for the [Reference Guide](https://github.com/apache/solr/tree/main/solr/solr-ref-guide) - [ ] I have added a [changelog entry](https://github.com/apache/solr/blob/main/dev-docs/changelog.adoc) for my change -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
