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-1701) Add NumericField and NumericSortField, make plain text numeric parsers public in FieldCache, move trie parsers to FieldCache
Date Fri, 19 Jun 2009 15:52:08 GMT

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

Uwe Schindler edited comment on LUCENE-1701 at 6/19/09 8:50 AM:
----------------------------------------------------------------

But the same problem like with NumericTokenStream affects also NumericField, because of type
safety it will only work with a setXxxValue (if not factory), e.g.
{code}
doc.add(new NumericField("price", precisionStep).setFloatValue(15.50f));
{code}

This code is not shorter than:
{code}
doc.add(NumericUtils.newFloatField("price", precisionStep, 15.50f));
{code}

Additionally with LUCENE-1699, we could also add Field.Store.XXX to the factory/ctor. 

OK, the factory solution has the problem, that you cannot reuse the field for effectiveness,
so this is an argument *for* the extra class, that has setXxXValue().

For SortField: The factory code inside NumericUtils is only one Line, you only create a conventional
SortField with a specific parser. If we do not want to have the factory in NumericUtils, I
could also add an additional ctor option to the normal sortfield (which is still there: it
takes the parser, LUCENE-1478). When all parsers are central in the FieldCache, one can create
a SortField with one line of code (the current factory demonstrates this).

      was (Author: thetaphi):
    But the same problem like with NumericTokenStream affects also NumericField, because of
type safety it will only work with a setXxxValue (if not factory), e.g.
{code}
doc.add(new NumericField("price", precisionStep).setFloatValue(15.50f));
{code}

This code is not shorter than:
{code}
doc.add(NumericUtils.newFloatField("price", precisionStep, 15.50f));
{code}

Additionally with LUCENE-1699, we could also add Field.Store.XXX to the factory/ctor.

For SortField: The factory code inside NumericUtils is only one Line, you only create a conventional
SortField with a specific parser. If we do not want to have the factory in NumericUtils, I
could also add an additional ctor option to the normal sortfield (which is still there: it
takes the parser, LUCENE-1478). When all parsers are central in the FieldCache, one can create
a SortField with one line of code (the current factory demonstrates this).
  
> Add NumericField and NumericSortField, make plain text numeric parsers public in FieldCache,
move trie parsers to FieldCache
> ----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: LUCENE-1701
>                 URL: https://issues.apache.org/jira/browse/LUCENE-1701
>             Project: Lucene - Java
>          Issue Type: New Feature
>          Components: Index, Search
>    Affects Versions: 2.9
>            Reporter: Uwe Schindler
>            Assignee: Uwe Schindler
>             Fix For: 2.9
>
>
> In discussions about LUCENE-1673, Mike & me wanted to add a new NumericField to o.a.l.document
specific for easy indexing. An alternative would be to add a NumericUtils.newXxxField() factory,
that creates a preconfigured Field instance with norms and tf off, optionally a stored text
(LUCENE-1699) and the TokenStream already initialized. On the other hand NumericUtils.newXxxSortField
could be moved to NumericSortField.
> I and Yonik tend to use the factory for both, Mike tends to create the new classes.
> Also the parsers for string-formatted numerics are not public in FieldCache. As the new
SortField API (LUCENE-1478) makes it possible to support a parser in SortField instantiation,
it would be good to have the static parsers in FieldCache public available. SortField would
init its member variable to them (instead of NULL), so making code a lot easier (FieldComparator
has this ugly null checks when retrieving values from the cache).
> Moving the Trie parsers also as static instances into FieldCache would make the code
cleaner and we would be able to hide the "hack" StopFillCacheException by making it private
to FieldCache (currently its public because NumericUtils is in o.a.l.util).

-- 
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