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 meaning,
hum...
memcached is a cache (developers don´t care about database)
memcachedb is a a database with memcache library protocol
membase is a database with memcache library protocol
if you want database features use membase or memcachedb
2011/3/4 Nathan Nobbe quickshif...@gmail.com:
On Thu, Mar
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.
Ah
On Mar 4, 12:21 pm, Jason Sirota ja...@sirotamail.com 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.
guys, the creators of this much loved tool -- viz-a-viz memcache -- designed
it with one goal in mind: CACHING!!
using sessions with memcache would only make sense from a CACHING
standpoint, i.e. cache the session values in your memcache server and if the
caching fails for some reason or another,
guys, the creators of this much loved tool -- viz-a-viz memcache -- designed
it with one goal in mind: CACHING!!
using sessions with memcache would only make sense from a CACHING standpoint,
i.e. cache the session values in your memcache server and if the
caching fails for some reason or
On Mar 4, 2011 10:38 PM, dormando dorma...@rydia.net wrote:
soo. it's more about matching the tool
vs your actual needs. most of the problem here has always been separating
perceieved requirements from actual requirements.
yeah, that's an incredibly
