Question about the expiration time in memcached mode
I was reviewing the protocol here, and had a question about the expiration time. It seems as though you have three options:
1. Pass in the absolute time_t value that the stored data should expire (in server time).
2. Pass in 0, which means that the data will more or less live indefinitely (or until an untimely asteroid strike, or out of memory, whichever comes first).
3. Pass in the number of seconds that the data should live.
This all makes sense for the 'set' or 'add' commands, but let's say you've already added data and now you want to update existing data, but still maintain the original expiration time? Unless I'm missing something, there doesn't seem to be a command for something like:
replace mykey 0 -1 9\r\n
datablock\r\n
where:
0 == flags
-1 == expiration time (-1 might mean, use original expiration)
9 == data block length.
Is there any other way to obtain from the server when an existing key will expire?
Thanks!
Yeah, that was kind of the conclusion I came to as well; I was just hoping I'd missed something. It's not a show-stopper; it was more for convenience than anything else.
I'm writing a simple c++ client library which uses boost to communicate with the server; I just prefer C++ over raw C.
Good to hear it's not a show-stopper. Either way I think replace should support this behavior and it's an easy fix. I added a feature request for this and will try to get around to fixing it soon.
I don't think that there is a way that you can keep the original expiration time. First off I just looked through the protocol and there isn't a way to to get the expiration time of an kv-pair. Second, you the protocol requires you to specify an expiration time every time you do a replace. It looks like what you are suggesting is having a special value that can be ignored if seen ( in this case -1). I think what might actually be better though is to be able to not include the expiration time. I'll put create a feature request for this, but jut so you know the fix will ost likely only support the binary protocol. I'll post a link to the request here later.