-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incrementing and decrementing key does not preserve its expiration (i.e. TTL) #59
Comments
I'm not sure if there are other options like |
@mattvleming Thanks for the report. I've spent a bit of time trying to re-work the way increment and decrement work, with the goal of using
The first option keeps the convenience of the library, but breaks atomicity and makes writing with expiration require four commands (read, read ttl, write, write ttl). The second option retains atomicity, simplifies the commands, but requires raw use of the redis client to initialize a value. I'm a bit torn on the direction right now. Input from others is welcome. |
@sorentwo Ya it's a tricky one. I played around with the I wonder if in addition to the first option you suggested above, you could provide developers a second option. So they two together would be:
Obviously this adds complexity to configuration of the gem, which is not great. That's one solution (allowing developers to turn on or off marshalling and encoding, which would influence the execution of increment and decrement). But I've just thought of another solution. Check this out:
A developer should never call increment and decrement on a key that isn't an integer. Also, you don't need to marshal values that are integers. So what you could do is, if the value that comes through And then if the developer tries to increment and decrement a key that doesn't have an integer value, you can catch that error from Redis and raise an exception to the developer saying you can't increment or decrement a value that isn't an integer. This means that |
The native incr/decr commands preserve a key's TTL. As readthis is unable to use those commands it uses a read/write cycle instead, which would clobber the TTL. Closes #59
Ruby Version: 2.3.5
Readthis Version: 2.0.2
Environment: macOS Sierra 10.12.6
If you open up a Redis command line, set a key/value with a TTL (time to live), then increment the key, the TTL stays:
If you do the same with a Readthis client however, the TTL will disappear:
It seems the cause is
#increment
and#decrement
don't call theincr
anddecr
Redis commands, but instead have their own implementation where they read the existing value and then write over it. But while doing so, these methods don't preserve the TTL of the key.It seems we're not calling
incr
anddecr
because Redis can't actually increment or decrement values for Readthis if Readthis encodes and marshals all values it sends to Redis. See 139553bThe text was updated successfully, but these errors were encountered: