search

lishunli / spymemcached

Automatically exported from code.google.com/p/spymemcached
0 stars 0 forks source link

incr/decr not working as expected #14

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Hi,

I'm having problems using the incr() / decr() methods of the
MemcachedClient - they basically do not what they promise.

Please see attached Test class and output to reproduce.

- memcached-2.0.jar
- spy.jar (2.4)

Cheers,
Mischa

Original issue reported on code.google.com by misch...@gmail.com on 27 Mar 2008 at 6:59

Attachments:

GoogleCodeExporter commented 9 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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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