Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Message-ID: <1488237032.1245674168522.JavaMail.jira@brutus>
Date: Mon, 22 Jun 2009 05:36:08 -0700 (PDT)
From: "Michael McCandless (JIRA)" <jira@apache.org>
To: java-dev@lucene.apache.org
Subject: [jira] Commented: (LUCENE-1701) Add NumericField and
 NumericSortField, make plain text numeric parsers public in FieldCache,
 move trie parsers to FieldCache
In-Reply-To: <1639192317.1245418147816.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org