[
https://issues.apache.org/jira/browse/LUCENE-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12721989#action_12721989
]
Michael McCandless commented on LUCENE-1701:
--------------------------------------------
bq. It's not sufficient for everyone, there will be (many) enhancements to
trie, and there will be other numeric field types. Trie is not, and should not
be the only numeric field, and should not be baked into the index format.
But trie is the best we have today?
And it's sooooo much better than we had before? Prior to trie, with
Lucene directly if you did a RangeQuery on a float/double field, it
was a nightmare. You had to get Solr's NumberUtils (or, roll your
own) to get something that even returned the correct results. Then,
you'll discover that performance was basically unusable.
The addition of numeric indexing to Lucene is a *major* step forward.
Why not make it work well with Lucene, today, and as these future
improvements arrive, we take them as they come? Design for today.
Anyway, if push comes to shove (which it *seems* to be doing!), I can
accept just returning a Field (not NumericField) from the document at
search time. I think it's a worse user experience, and will be seen
as buggy, but it would in fact mean zero change to the index format.
> 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
