incr/decr boundary conditions

0 views
Skip to first unread message

Marc

unread,
Jan 30, 2009, 9:02:59 PM1/30/09
to CloudCache.ws
What are the best ways to handle various incr/decr boundary
conditions?

Upper limit - should be 64-bit bigint?
Lower limit - negatives ok? negative 64-bit bigint?
What if key/val is not set when incr or decr is called? Should it be
set to 0, incr'd or decr'd, then return the result? Just return 0?
Or fail?

I note that in php land, Memcache::increment takes $key and optional
$value (int) - and if it is not numeric, it sets it to $value (seems
odd to me) - especially since if it doesn't exist, it does not create
it but returns FALSE.

Seems to me the most consistent and friendly approach would be:
1) Allow extreme limits, -2^63 .. 2^63
2) If it doesn't exist, create it and set it to either value (if
specified), else 0
3) If it exists and is non-numeric, return FALSE (and perhaps useful
message in body).

Thoughts?


m

Marc

unread,
Feb 6, 2009, 1:58:34 PM2/6/09
to CloudCache.ws
Also, would be grateful for feedback on most ReSTful way to implement
incr/decr .

Here's one idea: POST http://cloudcache.ws/mycounter++ and /
mycounter--

If a val is passed, it should be castable to an integer, and this val
will be used to increment or decrement the counter. Else, val is 1.

Why POST instead of GET or PUT? GET should be a "Safe" method
according to the rfc. And PUT is about the whole entity. POST on the
other hand is for changing existing resources...

Rather than passing the val in the POST data, we could instead support
a format like this: http://cloudcache.ws/mycounter+27 for
incrementing by something other than 1. The problem with using POST
for that is that post has to pass some data... - perhaps just an empty
string?

Thanks in advance for the feedback,


m

Travis Reeder

unread,
Feb 6, 2009, 2:08:12 PM2/6/09
to cloudc...@googlegroups.com
I don't think you should use '+' signs, those are escape characters in URL's. Maybe http://cloudcache.ws/mycounter/inc
and 
http://cloudcache.ws/mycounter/dec
and
and
http://cloudcache.ws/mycounter - returns the value

I wouldn't worry too much about the post/get thing with something like this though, POST seems overkill.

Travis

Marc Byrd

unread,
Feb 6, 2009, 2:31:39 PM2/6/09
to cloudc...@googlegroups.com
I'm inclined to stick w/ post - get is supposed to be safe...

How about post /mycounter/incr , /mycounter/decr , with val passed in via data, and if not there, 1 is implied?

m

Marc

unread,
Feb 7, 2009, 3:59:49 PM2/7/09
to CloudCache.ws
Ok, i've implemented incr and decr with the following API:
increment by 1: POST http://cloudcache.ws/<key>/incr ; data is empty
or doesn't contain val or val=1
increment by <val> : POST http://cloudcache.ws/<key>/incr ; data
contains val=<val>
Likewise for decr.

If key/val doesn't exist in CC, error is returned.

If val exists for key in CC, but val is not numeric, it is set to 1.

If val is 0 when decr called, 0 is returned.

If val is 64-bit unsigned bigint when incr is called, it wraps.

These are all consistent with the memcached server API, which makes
for easy drop-in replacement of potential CloudCache libs in place of
existing memcached libs (requires only a constructor change).

Simple python examples of usage are provide in incr.py and decr.py in
the google-code for cloudcache-python here -
http://code.google.com/p/cloudcache-python/source/browse/trunk/

Cheers,

m


On Feb 6, 11:31 am, Marc Byrd <m...@cloudscape.ws> wrote:
> I'm inclined to stick w/ post - get is supposed to be safe...
>
> How about post /mycounter/incr , /mycounter/decr , with val passed in via
> data, and if not there, 1 is implied?
>
> m
>
> On Fri, Feb 6, 2009 at 11:08 AM, Travis Reeder <tree...@gmail.com> wrote:
> > I don't think you should use '+' signs, those are escape characters in
> > URL's. Maybehttp://cloudcache.ws/mycounter/inc<http://cloudcache.ws/mycounter++>
> > andhttp://cloudcache.ws/mycounter/dec<http://cloudcache.ws/mycounter++>
> > and
> >http://cloudcache.ws/mycounter/add/3<http://cloudcache.ws/mycounter++>
> > and
> >http://cloudcache.ws/mycounter<http://cloudcache.ws/mycounter++> -
> > returns the value
>
> > I wouldn't worry too much about the post/get thing with something like this
> > though, POST seems overkill.
>
> > Travis
>
> > On Fri, Feb 6, 2009 at 10:58 AM, Marc <dr.marc.b...@gmail.com> wrote:
>
> >> Also, would be grateful for feedback on most ReSTful way to implement
> >> incr/decr .
>
> >> Here's one idea:  POSThttp://cloudcache.ws/mycounter++and /
Reply all
Reply to author
Forward
0 new messages