Hi,

On Wed, Apr 10, 2013 at 2:45 AM, Adrien Grand <jpou...@gmail.com> wrote:

> Hi,
>
> On Wed, Apr 10, 2013 at 9:34 AM, Wei Wang <welshw...@gmail.com> wrote:
> > IntField inherits from Field class a function called setByteValue().
> > However, if we call it, it gives an error message:
> >
> > java.lang.IllegalArgumentException: cannot change value type from Integer
> > to Byte
> >
> > 1. If this not allowed for IntField, and there is no ByteField, how will
> > function setByteValue() be used?
>
> The rule is that if your Field instances wrap an object whose type is
> XXX, you should only use the setXXXValue setter. Other setters will
> throw an exception instead of performing automatic type conversions in
> order to detect programming errors. This is why setByteValue threw an
> exception on your IntField.
>

Okay. Since there is no ByteField, setByteValue will never by used. It
seems like a dead function.

>
> > 2. Will IntField automatically detect value range is small and use less
> > space? I understand DocValuesField can save space by using variable
> length
> > codec, but not sure about IntField.
>
> They are very different:
>  - A DocValues field stores one value per document ID.
>  - An indexed field only stores distinct values, and associate with
> every dictinct value the list of document IDs that contain this value
> (this is called a postings list).
>
> Indexed values are not compressed but the postings lists are, and the
> compression ratio is better when postings lists are dense (with the
> current default postings format at least). This makes indexed fields
> (such as IntField) use less space when the number of dictinct values
> is small.
>

That makes sense. If we don't need positional info (virtually all terms are
at the same position), can we control this for IntField or any other Field?

>
> --
> Adrien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
> For additional commands, e-mail: java-user-h...@lucene.apache.org
>
>

Reply via email to