Ok, finally got some time to dig into this and you were exactly right. I
simply needed to provide the offset of the payload when scoring it in my
custom similarity.
EG: PayloadHelper.decodeFloat(payload.bytes, payload.offset);
Simple! Thanks for the help.
Jim
--
View this message in context:
I appreciate your help with this!
I was attempting to follow your advice when I noticed another odd behavior
that leads me to believe they are not being stored correctly.
If I add two documents at once using solr's update handler like so:
[{"id":"1","foo_ap":"bar|50"}},{"id":"2","foo_ap":"bar|75
Most likely, the cause is what I said. I guess when you try to convert
bytes to number you didn't use the payload.offset to locate the right start
of bytes. Before 4.1, the start of payload is the expected value. But since
4.1, you must use the offset and length to get the correct bytes you
wanted.
Thanks for the response. I wrote some new custom payload functions to verify
that I'm getting the value correctly and I think I am, but I did unearth
this clue.
In the docs below, the score should be the sum of all the payloads for the
term "bing". It appears to be using the value for the first te
I'm not sure your problem relates to the function or getting payload itslef.
But after 4.1, in DefaultSimilarity.scorePayload(int doc, int start, int
end, BytesRef payload), you must leverage payload.offset and payload.length
to get the bytes. (start and end won't get the exact bytes you want).
Ho
I have some custom Payload Functions that worked great up until version 4.1
and now I can't get any of them to work correctly. In fact, the existing
ones -- AveragePayloadFunction, MaxPayloadFunction, and MinPayloadFunction
don't seem to work properly either.
This may be a problem in Solr, but sin
