[
https://issues.apache.org/jira/browse/LUCENE-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12721979#action_12721979
]
Michael McCandless commented on LUCENE-1701:
--------------------------------------------
I still think we should make NumericSortField strongly typed (not a
factory method that returns a SortField w/ the right parser).
I think it's far more consumable, from the user's standpoint. I made
a NumericField when indexing so making a NumericSortField to sort
makes it "obvious".
Ie this:
{code}
new NumericSortField("price");
{code}
is better than this:
{code}
new SortField("price", FieldCache.NUMERIC_FLOAT_PARSER);
{code}
or this:
{code}
SortField.getNumericSortField("price", SortField.FLOAT);
{code}
Uwe, I agree that if we take the developer's (us) standpoint, the
implementation of NumericSortField is so trivial (just pick the right
parser) that it's tempting to not name the class. But from the user's
standpoint it's less consumable.
bq. Regardless of the fact that plain_int parser is on FieldCache, it still
doesn't seem like we should add parsers to FieldCache for every field type.
{Extended,}FieldCache already is the central place that holds parsers
for all of Lucene's core types; why change that? Leaving Numeric* out
is dangerous because then people will naturally assume getFloats() is
the method to call.
> 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
>
> Attachments: NumericField.java
>
>
> 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
