Uwe Schindler wrote:
>
>> My personal opinion is that we can make javadoc changes for the final
>> without doing an RC, as long as no code/build/scipts at all is touched.
>> Not sure how others feel though.
>>
>
> I just wanted to ask for confirmation.
>
> Uwe
>
>
I know - we always should
> > If we do not need a new RC fort hat I can do it tomorrow! I am not yet
> sure
> > what to write: I tend to say: "Use NumericField, but with infinite
> > precisionStep for low-cardinality fields - and you get the old TermEnum
> > value list as before (with conversion through NumericUtils)". In
>
Uwe Schindler wrote:
Maybe I add this t the javadocs.
>> +1 - intuition might be to use it for anything numeric.
>>
>
> If we do not need a new RC fort hat I can do it tomorrow! I am not yet sure
> what to write: I tend to say: "Use NumericField, but with infinite
> pre
> >> Maybe I add this t the javadocs.
> >>
> +1 - intuition might be to use it for anything numeric.
If we do not need a new RC fort hat I can do it tomorrow! I am not yet sure
what to write: I tend to say: "Use NumericField, but with infinite
precisionStep for low-cardinality fields - and you get
>> NumericField uses a spezial encoding of terms for fast NumericRangeQueries.
>> It indexes more than one term per value. How many terms depends on the
>> precisionStep ctor parameter. If you set it to infinity (or something ge the
>> bit size of your value, 32 for ints, it indexes exactly one va
Hi Uwe,
Thanks for the explanation! It really helps. That makes sense that for
a small number of values, such as "hour" NumericField is not going to
help me. I'm experimenting with using epoch NumericField for sorting,
which funnily is where I started with 2.4.1, before going down the
usual TooMan
Hi Phil,
thanks for checking out NumericField. I have two comments about your
problem:
> I've used NumericField to store my "hour" field.
>
> Example...
>
> doc.add(new
> NumericField("hour").setIntValue(Integer.parseInt("12")));
NumericField uses a spezial encoding of terms for fast Nume