In reading the binary spec document
http://code.google.com/p/memcached/wiki/BinaryProtocolRevamped it isn't
clear that the value to be incremented/decremented must be the char
representation of a number (0x31 for 1 for example) rather than an integer
representation (e.g. 0x00 00 00 01) even though
On Mar 2, 9:13 pm, Jason Sirota wrote:
> In reading the binary spec
> documenthttp://code.google.com/p/memcached/wiki/BinaryProtocolRevampedit isn't
> clear that the value to be incremented/decremented must be the char
> representation of a number (0x31 for 1 for example) rather than an integer
On 3. mars 2011, at 23.10, Dustin wrote:
>
> On Mar 2, 9:13 pm, Jason Sirota wrote:
>> In reading the binary spec
>> documenthttp://code.google.com/p/memcached/wiki/BinaryProtocolRevampedit
>> isn't
>> clear that the value to be incremented/decremented must be the char
>> representation of a
>
> This makes sense, though it's not binary protocol specific.
>
> The binary protocol has the advantage of managing the creation,
> modification, and retrieval of the value abstractly. Ideally, you
> wouldn't set the value independently of the incr or decr commands.
>
If I understand your mea
On Mar 4, 8:38 am, Jason Sirota wrote:
> If I understand your meaning, it's unlikely you would first *set *a value
> and then later incr/decr it. By extension it also means that would not
> likely *get *a counter outside of the return value of incr/decr so the
> underlying representation of that
>
> I'm not so much saying it's unlikely, but it's certainly
> unnecessary.
>
> In my java client, for example, you could incr and decr with default
> to start and move the counter. Then you could incr by 0 to get the
> number *as* a number vs. a regular get that will get the number as
> text.
>
On Mar 4, 12:21 pm, Jason Sirota wrote:
> > It's not an uncommon pattern to (add k "0") then (incr k) then (get
> > k) => "1"
>
> Out of curiosity then, why is the values stored as a string? Is it just for
> historical reasons? space?
Mostly historical (compatibility) reasons.
People expec
Here's another odd point on INCR/DECR ...
The default engine will not decrement an item to less than zero.
The "binary decr" test in memcapable also asserts that you can't do
that. There's a comment:
/* decr 0 should not wrap */
But the spec on the wiki also doesn't mention anything one w
On 7. mars 2011, at 17.45, John David Duncan wrote:
> Here's another odd point on INCR/DECR ...
>
> The default engine will not decrement an item to less than zero.
> The "binary decr" test in memcapable also asserts that you can't do that.
> There's a comment:
>
> /* decr 0 should not wrap
