[
https://issues.apache.org/jira/browse/LUCENE-1673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12719689#action_12719689
]
Michael McCandless commented on LUCENE-1673:
--------------------------------------------
bq. So one using new code must always specify the parser when using
SortField.INT (SortField.AUTO is already deprectaed so no problem).
This will apply to int/long/float/double as well right? How would you
do this (require a parser for only numeric sorts) back-compatibly? EG,
the others (String, DOC, etc.) don't require a parser.
We could alternatively make NumericSortField (subclassing SortField),
that just uses the right parser?
Did you think about / decide against making a NumericField (that'd set
the right tokenStream itself)?
Other questions/comments:
* Could we change ShiftAttribute -> NumericShiftAttribute?
* How about oal.util.NumericUtils instead of TrieUtils?
* Can we rename RangeQuery -> TextRangeQuery (TermRangeQuery), to
make it clear that its range checking is by Term sort order.
* Should we support byte/short for trie indexed fields as well?
(Since SortField, FieldCache support these numeric types too...).
> Move TrieRange to core
> ----------------------
>
> Key: LUCENE-1673
> URL: https://issues.apache.org/jira/browse/LUCENE-1673
> Project: Lucene - Java
> Issue Type: New Feature
> Components: Search
> Affects Versions: 2.9
> Reporter: Uwe Schindler
> Assignee: Uwe Schindler
> Fix For: 2.9
>
> Attachments: LUCENE-1673.patch, LUCENE-1673.patch
>
>
> TrieRange was iterated many times and seems stable now (LUCENE-1470,
> LUCENE-1582, LUCENE-1602). There is lots of user interest, Solr added it to
> its default FieldTypes (SOLR-940) and if possible I want to move it to core
> before release of 2.9.
> Before this can be done, there are some things to think about:
> # There are now classes called LongTrieRangeQuery, IntTrieRangeQuery, how
> should they be called in core? I would suggest to leave it as it is. On the
> other hand, if this keeps our only numeric query implementation, we could
> call it LongRangeQuery, IntRangeQuery or NumericRangeQuery (see below, here
> are problems). Same for the TokenStreams and Filters.
> # Maybe the pairs of classes for indexing and searching should be moved into
> one class: NumericTokenStream, NumericRangeQuery, NumericRangeFilter. The
> problem here: ctors must be able to pass int, long, double, float as range
> parameters. For the end user, mixing these 4 types in one class is hard to
> handle. If somebody forgets to add a L to a long, it suddenly instantiates a
> int version of range query, hitting no results and so on. Same with other
> types. Maybe accept java.lang.Number as parameter (because nullable for
> half-open bounds) and one enum for the type.
> # TrieUtils move into o.a.l.util? or document or?
> # Move TokenStreams into o.a.l.analysis, ShiftAttribute into
> o.a.l.analysis.tokenattributes? Somewhere else?
> # If we rename the classes, should Solr stay with Trie (because there are
> different impls)?
> # Maybe add a subclass of AbstractField, that automatically creates these
> TokenStreams and omits norms/tf per default for easier addition to Document
> instances?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
