lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (LUCENE-1673) Move TrieRange to core
Date Sun, 14 Jun 2009 16:16:07 GMT

    [ https://issues.apache.org/jira/browse/LUCENE-1673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12719292#action_12719292
] 

Uwe Schindler edited comment on LUCENE-1673 at 6/14/09 9:14 AM:
----------------------------------------------------------------

Here is a first patch, just for initial review of the API.
- Only 5 new classes in core (NumericRangeQuery, NumericRangeFilter [each with factory for
data types], NumericTokenStream [with one ctor using precStep, various setValue() methods],
ShiftAttribute)
- TrieUtils still by that name, because a new name is not yet thought about (and how to deprecate
NumberUtils from solr in contrib/spatial, deprecate o.a.l.document.NumberTools)
- All tests rewritten & pass
- Javadocs still incomplete and need to be rewritten (add package.html from contrib to search's/analysis'
package.html and so on)

You may ask, why I added these static factories to NumericRangeQuery/Filter, one could directly
instantiate the class using any subclass of java.lang.Number? Because type safety to prevent
people from doing things like new NumericRangeQuery(field,precStep,new Long(val1),new Float(val2))
which may lead to undefined behaviour. The second problem is missing type safety with auto-boxing
in Java 5.

      was (Author: thetaphi):
    Here is a first patch, just for initial review of the API.
- Only 5 new classes in core (NumericRangeQuery, NumericRangeFilter [each with factory for
data types], NumericTokenStream [with one ctor using precStep, various setValue() methods],
ShiftAttribute)
- TrieUtils still by that name, because a new name is not yet thought about (and how to deprecate
NumberUtils from solr in contrib/spatial, deprecate o.a.l.document.NumberTools)
- All tests rewritten & pass

You may ask, why I added these static factories to NumericRangeQuery/Filter, one could directly
instantiate the class using any subclass of java.lang.Number? Because type safety to prevent
people from doing things like new NumericRangeQuery(field,precStep,new Long(val1),new Float(val2))
which may lead to undefined behaviour. The second problem is missing type safety with auto-boxing
in Java 5.
  
> 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
>
>
> 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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message