the decodeLong method in the TranscoderUtils class return wrong values about spymemcached

[GoogleCodeExporter]

The differences is that in the incr or decr use an other decodeLong algorithm 
than
the get method.

See here

that incr/decr : rv.set(new Long(s.isSuccess()?s.getMessage():"-1"))

get : public long decodeLong(byte[] b) {
        long rv=0;
        for(final byte i : b) {
            rv = (rv << 8) | (i<0?256+i:i);
        }
        return rv;
    }

Original comment by [email protected] on 12 Dec 2008 at 2:47

[GoogleCodeExporter]

If I understand your concern correctly, this is by spec.

The stored value *must* be a string representation for these operations, not a
numeric one.  incr with 0 will give you a numeric result, otherwise, you should
expect a string result.

If this isn't what you're talking about, please reopen.

Original comment by [email protected] on 19 Dec 2008 at 4:00

• Changed state: Invalid

[GoogleCodeExporter]

Okay,

but I understand that but should the get command also return the current counter
value (but this doesn't work) incr store a string and translated for me back to 
a
Long but the get command interpret the stored string as a Long and use the 
decodeLong
method to translated it into a long value.

Is there no way to get the current counter value?

Original comment by [email protected] on 21 Dec 2008 at 4:55

[GoogleCodeExporter]

Yes, you incr 0 to get the current value.

Or you do a get and get it back in string form and convert it.

It's unfortunate, but it'd be very complicated to do it a different way (the 
server
would have to know how these values are used, which it doesn't currently except
during incr and decr calls).

Original comment by [email protected] on 22 Dec 2008 at 4:18