[
https://issues.apache.org/jira/browse/LUCENE-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12722577#action_12722577
]
Michael McCandless commented on LUCENE-1701:
--------------------------------------------
{quote}
bq. Could you add the "<b>NOTE:</b> This API is experimental and might change
in incompatible ways in the next release." caveat to the javadocs?
For the whole TrieAPI or only NumericUtils? If the first, I would do this with
an general JavaDoc commit after this issue. If only NumericField, I could do it
now.
{quote}
For the whole thing; I think an added NOTE at each class level
javadoc is what we need. A separate javadoc issue is good, but
it needs to be done for 2.9.
{quote}
bq. Can you change this:
Sure, we had this the last time, too (I like my variant more, so I always
automatically write it in that way)
{quote}
Which "last time"? Is there somewhere in the code base now where
we do this?
We generally try (though, don't always succeed) to follow Sun's coding
guidelines (http://java.sun.com/docs/codeconv/) except 2-space indent
not 4.
{quote}
bq. I think we can't actually deprecate NumberTools until we can call
FieldCache.getShorts/getBytes on a NumericField? Ie, people relying on
short/byte (to consume much less memory in FieldCache) cannot switch to
numeric, and so must continue to zero-pad if they need to use RangeQuery/Filter?
NumberTools does not handle zero-padding, so it could stay deprecated. Numbers
encoded with NumberTools cannot be natively sorted on at all (only using
StringIndex) and can only handle longs.
{quote}
Actually, I believe it does do 0 padding and handles negative numbers
correctly (NumberTools.longToString)?
Ie, I can take a short now, call longToString, index with that, do
[possibly inefficient] RangeQuery against it, and sort against it
using only 2 bytes per doc, today?
bq. I will open an issue because of this byte/short trie fields (LUCENE-1710)
OK but since we've marked it 3.1 (which I think is OK; though in
CHANGES lets document the limitation?), we should un-deprecate
NumberTools, now, and deprecate it again along with LUCENE-1710?
> 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: LUCENE-1701-test-tag-special.patch, LUCENE-1701.patch,
> LUCENE-1701.patch, LUCENE-1701.patch, LUCENE-1701.patch, LUCENE-1701.patch,
> 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
