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.
Best regards,
Duke
If not now, when? If not me, who?
On Fri, Mar 22, 2013 at 6:37 PM, jimtronic <jimtro...@gmail.com> wrote:
> 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 term/payload it
> sees for every term it finds.
>
> {
> "id":"3",
> "foo_ap":["bing|7 bing|9",
> "bing|9 bing|7"],
> "score":28.0},
> {
> "id":"2",
> "foo_ap":["bing|9",
> "bing|7"],
> "score":18.0},
> {
> "id":"4",
> "foo_ap":["bing|9 bing|7"],
> "score":18.0},
> {
> "id":"1",
> "foo_ap":["bing|9"],
> "score":9.0}
> ]
>
> Now, the question is whether this is a storage problem or a retrieval
> problem...
>
>
>
>
> --
> View this message in context:
> http://lucene.472066.n3.nabble.com/PayloadFunctions-don-t-work-the-same-since-4-1-tp4049947p4049999.html
> Sent from the Lucene - Java Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
> For additional commands, e-mail: java-user-h...@lucene.apache.org
>
>
