[
https://issues.apache.org/jira/browse/LUCENE-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12722579#action_12722579
]
Uwe Schindler commented on LUCENE-1701:
---------------------------------------
{quote}
bq. Sure, we had this the last time, too (I like my variant more, so I always
automatically write it in that way)
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}
This was not against the change. With "last time" I meant that some time ago
you mentioned the same in a different patch from me. I will change it.
My note was only, that I "automatically" create such code, because I for myself
find its better readable. That was all :-)
{quote}
bq. 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.
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?
{quote}
You cannot do this with NumberTools. NumberTools uses an special radix 36
encoding (and not radix 10 like normal numbers). The encoding is just like
NumericUtils not human-readable and so cannot be parsed with Number.toString().
To convert back, you need the method from the same class.
Because of this you have two possilities: Write your own parser and pass it to
SortField/FieldCache or sort using StringIndex (because it is sortable
according to String.compareTo).
So it can be deprecated.
If sombody want to do encoding and parsing with FieldCache.getShorts() there is
no way around a DecimalFormat with zero-padding and the problem with negative
numbers.
> 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
