You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If call the incr method to increment a counter this method return the new
value of the counter but if I perform a get on the incremented counter than
i get a different value.
Original issue reported on code.google.com by pussinbo...@googlemail.com on 12 Dec 2008 at 2:27
The text was updated successfully, but these errors were encountered:
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 pussinbo...@googlemail.com on 12 Dec 2008 at 2:47
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 dsalli...@gmail.com on 19 Dec 2008 at 4:00
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 pussinbo...@googlemail.com on 21 Dec 2008 at 4:55
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 dsalli...@gmail.com on 22 Dec 2008 at 4:18
Original issue reported on code.google.com by
pussinbo...@googlemail.com
on 12 Dec 2008 at 2:27The text was updated successfully, but these errors were encountered: