Closed GoogleCodeExporter closed 8 years ago
The problem is that incr and decr are defined to operate on strings in the
protocol,
and integers are encoded in a sort of binary format by the serializing
transcoder.
If you use incr with a default, or just set the string value of your input,
it'll do
what you want.
I'll have to close this as working as expected. The only potential code change
I
could make would be a new transcoder that represents ints as strings, or a
configurable behavior on SerializingTranscoder.
Original comment by dsalli...@gmail.com
on 29 Mar 2008 at 7:51
Ok, thanks.
I tried it by setting the value as String and it worked fine.
The only other thing I have noticed it that if decr results in a value with less
digits you have to trim the trailing whitespace(s).
e.g.
@Test
public void testSetAndDecr()
{
String key = "keySetAndDecr";
String value = "10";
mcc.set(key, value);
assertTrue(mcc.get(key).equals(value));
mcc.decr(key, 9);
// System.out.println(">>>>>>>>" + ((String)mcc.get(key)).replaceAll("\\s+",
"x")); // shows the trailing whitespace as x, e.g. 1x
assertTrue(((String) mcc.get(key)).trim().equals("1")); // I would have expected
that the result is cleaned up already
}
Original comment by misch...@gmail.com
on 31 Mar 2008 at 9:32
Yeah, that's another annoying part of the protocol spec. It's just what
memcached does.
The good news is that I've fixed this behavior in the binary protocol (since you
actually get numbers back).
Original comment by dsalli...@gmail.com
on 31 Mar 2008 at 7:32
Original issue reported on code.google.com by
misch...@gmail.com
on 27 Mar 2008 at 6:59Attachments: