Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-user@lucene.apache.org
Received-SPF: pass (nike.apache.org: domain of mindas@gmail.com designates
 72.14.220.159 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=UMqca9s3X93SqIzAT1/JRzcCDfROP2K5Y6xeKWNc+WSvZSnk6zAhXEqFerIiuAY4C0
         qbJhPs3NUz2amPpHIoS99Iu0c8qqzolgHinISsP9dAWLlEoR+mhhX0vUKbpvZWJ1sgKV
         PHXGHN60jHaiKXSU7XkaDgZlYcpTs1xoFxSkA=
MIME-Version: 1.0
In-Reply-To: <00b101cb0186$b2571cd0$17055670$@thetaphi.de>
References: <AANLkTilt4WO722-T1t4uxqwggOwEQajn5mXTlo4YAr8g@mail.gmail.com>
	<00b101cb0186$b2571cd0$17055670$@thetaphi.de>
Date: Tue, 1 Jun 2010 14:34:20 +0100
Message-ID: <AANLkTim4KJXe9WBJZkvjg3F1FWQ2G3R6dHTq_MuLkf6q@mail.gmail.com>
Subject: Re: NumericField API
From: =?ISO-8859-13?Q?Mindaugas_=DEak=F0auskas?= <mindas@gmail.com>
To: java-user@lucene.apache.org
Content-Type: text/plain; charset=ISO-8859-1

Hi,

Thanks for your reply Uwe. Just a couple of notes:

>> In order to get rid of this exception, I had to change one of the
> following:
>> - SortField must be changed from SortField.STRING to SortField.LONG
>
> This does the trick and is *not* weird. You are using *numeric* fields, so
> you cannot sort as lexical *terms/strings*

Fair enough. I don't know if this is easily doable, but maybe it would
be worth changing the exception text to be a bit more readable?
Because I had to spend a fair amount of time digging into
"creationDate field has become tokenized? How could that happen for
numeric fields?" direction. As from your answer - all that matters in
this case is the sorting rather than indexing.

> The above exception may be caused by something different: Can it be that you
> have an old index that already had non-NumericField documents in it? If this
> is so, you have a mixed field contents and then behavior of range query and
> sort is wrong.

I have completely reindexed all documents so this clearly isn't the case.

>
>> 3) NumericField API is marked as experimental and volatile
>> (http://lucene.apache.org/java/3_0_1/api/core/index.html). Is there any
>> other "stable" API I can rely on in Lucene 3.0? If not, what would be
> possible
>> NumericField replacement I could use now?
>
> "Experimental" in Lucene's API *only* means that the API (method signatures,
> classes) may change suddenly. The features are tested and working.

My point was - I totally understand that a piece of API could have
been made deprecated and  replaced with something else. That's the
life we're living. But would it not then make sense to replace it with
something else which is also reasonably stable (in terms of API)?

Because developers aren't left with many options now - they have to
convert from using one API which is unavailable to another which is
likely to change rather sooner than later. It's just an early
observation as historically Lucene has been doing an amazing job in
terms of API stability.

Regards,
Mindaugas

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org