gerlowskija commented on PR #4141:
URL: https://github.com/apache/solr/pull/4141#issuecomment-3916791411
So, I wanted to highlight some design choices for potential reviewers -
these are decisions I made in putting this together that 100% need a second set
of eyes:
1. Currently I've made no effort to integrate this new field type into
lucene, dismax, or edismax query parsers. In other words, users **must** use
the new `{!numericRange}` QParser for any queries against these fields.
2. Overall review of the naming around `{!numericRange}`. Is "numericRange"
clear enough for users? Is "criteria" a decent name for indicating the
match-criteria strategy, or do folks have other ideas there?
3. Currently, the `{!numericRange}` QParser treats "field" and "criteria" as
required - users must specify them explicitly on each request. If we wanted,
we could make a certain 'criteria' value the default to simplify invocation for
some users. But I'm not sure what the most common 'criteria' would be in
practice, so I've held off on this.
4. Users can achieve inclusive/exclusive semantics on queries by
incrementing/decrementing the int vals in their queries. But if we could
expose explicit parameters (e.g. `lowerExclusive=true`) to do this
automatically if we think it's worth taking on a bit of extra complexity to
simplify this for users.
5. I've put all the new classes in a 'numericrange' sub-package. This is a
bit unnecessary currently, but I hope in follow-on PRs to add field types and
query support for float, long, etc. So I suspect we'll end up with enough
classes in the medium term to merit this being its own package.
Still TODO
- changelog
- performance tests
--
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]
