No no, not irony at all. I misunderstood the first time. You wrote "is
there any way to get ByteRef from a field originally stored as String?", so
I understand the first thing that came to mind :).
But I understand the question now -- you say that since the String field is
written as byte[] in the file, you want to read the byte[] as they are,
without translating them to String. right?
I don't know if it's possible. I'd try field.binaryValue(), though looking
at the impl it doesn't suggest it will do what you want.
Shai
On Sun, Mar 17, 2013 at 3:02 PM, eksdev <eks...@googlemail.com> wrote:
> Shai, was that irony or I am missing something big time?
>
> I would like to spare BytesRef -> String conversion, not to introduce
> another one back to BytesRef
>
> Simply, for sorting, you do not need to do this byte[]->String conversion,
> byte representation of the String is perfectly sortable…
>
>
>
> On Mar 17, 2013, at 1:53 PM, Shai Erera <ser...@gmail.com> wrote:
>
> You can do new BytesRef(d1.get("fieldName")).
>
> Shai
>
>
> On Sun, Mar 17, 2013 at 2:43 PM, eksdev <eks...@googlemail.com> wrote:
>
>> is there any way to get ByteRef from a field originally stored as String?
>>
>> I am playing with Sorter to implement StoredDocSorter, analogous to
>> NumericDocValuesSorter. But realised I do not need ByteRef - > String
>> conversion just to compare fields (byte order would be as good for sorting)
>>
>> StoredDocument d1 = reader.document(docID1, fieldNamesSet);
>> String value1 = d1.get("fieldName")
>> String value1 = d1.getStringAsBytesValue("fieldName")// would love to
>> have it
>>
>> I need String type in other places, so indexing as byte[] would be too
>> much hassle.
>>
>> String is internally stored as byte[], no reason not to expose it for
>> StoredField (or any other type)?
>>
>>
>>
>
>
