Re: BinaryDocValues prefix bytes

[Dominik Safaric]

No I'm not. The values are being stored through ElasticSearch into a binary
doc value as a base 64 encoded string.

2018-02-28 16:00 GMT+01:00 David Smiley <david.w.smi...@gmail.com>:

> This can't be; it must be a bug.  Perhaps you are saving away the BytesRef
> by reference across multiple invocations?  That won't work; you may have to
> clone/copy it.
>
> On Wed, Feb 28, 2018 at 9:53 AM Dominik Safaric <dominiksafa...@gmail.com>
> wrote:
>
>> Hi,
>>
>> I'm having an index where I'm storing a binary doc value being equal to a
>> serialized 8 byte value. The values are consumed by a custom Query
>> implementation, using LeafReader.getBinaryDocValues().
>>
>> However, what I found is the following. To each binary doc value returned
>> by BinaryDocValues.get(docID), a sequence of two bytes of appended. In
>> particular, at the first position it is always a byte equal to 1, whereas
>> at the second position always a byte equal to 8. Hence, the length of the
>> retrieved byte array is always equal to 10, and not 8 as stored.
>>
>> Could please someone explain why are these bytes being appended at the
>> head of the array, where are these bytes appended and how to get the
>> original value?
>>
>> Kind regards,
>> Dominik
>>
> --
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.
> solrenterprisesearchserver.com
>

BinaryDocValues prefix bytes

[Dominik Safaric]

Hi,

I'm having an index where I'm storing a binary doc value being equal to a
serialized 8 byte value. The values are consumed by a custom Query
implementation, using LeafReader.getBinaryDocValues().

However, what I found is the following. To each binary doc value returned
by BinaryDocValues.get(docID), a sequence of two bytes of appended. In
particular, at the first position it is always a byte equal to 1, whereas
at the second position always a byte equal to 8. Hence, the length of the
retrieved byte array is always equal to 10, and not 8 as stored.

Could please someone explain why are these bytes being appended at the head
of the array, where are these bytes appended and how to get the original
value?

Kind regards,
Dominik

PointValues ordering

[Dominik Safaric]

Given a multi-valued and non-indexed point value field, how does Lucene 
internally store this kind of fields, in terms or order and may they be 
retrieved in the same order as stored? For example, given a document and an 
associated field equal to plongField: [1,2,3], and using a DocIdSetIterator, 
how can I retrieve these values in the same order as inserted during for 
example scoring using a CustomScoreProvider?

Cheers,
Dominik