WATCH + expires

[Salvatore Sanfilippo]

Hello,

I just noticed that WATCH is not affected by the server removing a key
because of an expire set. This sounds wrong, I imagine I may want to
modify a given key only if the key is still there in case there is an
expire set, like in:

r = Redis.new
r.del(:foo)
r.lpush(:foo,"A")
r.expire(:foo,2)
sleep(3)
r.watch(:foo)
r.multi {
r.lpush(:foo,"B")
}

The EXEC gets executed while it should IMHO fail.

What's your feeling? The change is trivial, it's just a matter of
deciding what behavior we feel correct.

Cheers,
Salvatore

--
Salvatore 'antirez' Sanfilippo
open source developer - GoPivotal
http://invece.org

Beauty is more important in computing than anywhere else in technology
because software is so complicated. Beauty is the ultimate defence
against complexity.
— David Gelernter

[bugant]

Ciao Salvatore,

On Wed, Aug 7, 2013 at 11:55 AM, Salvatore Sanfilippo <ant...@gmail.com> wrote:
> I just noticed that WATCH is not affected by the server removing a key
> because of an expire set. This sounds wrong, I imagine I may want to
> modify a given key only if the key is still there in case there is an
> expire set, like in:

I do agree, by the way I think this should happen only if you were
watching a key before it gets expired.

> r = Redis.new
> r.del(:foo)
> r.lpush(:foo,"A")
> r.expire(:foo,2)
> sleep(3)
> r.watch(:foo)
> r.multi {
> r.lpush(:foo,"B")
> }

so to rephrase the code above to make it fails, I'd do something like:

r = Redis.new
r.del(:foo)
r.lpush(:foo, "A")
r.expire(:foo, 2)

r.watch(:foo)
sleep(3)

r.multi { r.lpush(:foo, "B") }

Cheers,
matteo.

[Salvatore Sanfilippo]

On Wed, Aug 7, 2013 at 12:10 PM, bugant <bug...@gmail.com> wrote:
> I do agree, by the way I think this should happen only if you were
> watching a key before it gets expired.

Sure, that's the basic semantics, only if the change happens *after*
you WATCH the EXEC will be affected.

[Jay A. Kreibich]

On Wed, Aug 07, 2013 at 11:55:47AM +0200, Salvatore Sanfilippo scratched on the wall:

> Hello,
>
> I just noticed that WATCH is not affected by the server removing a key
> because of an expire set.

[...]

> The EXEC gets executed while it should IMHO fail.
>
> What's your feeling? The change is trivial, it's just a matter of
> deciding what behavior we feel correct.

Agreed. The key was modified; the WATCH should fail.

-j

--
Jay A. Kreibich < J A Y @ K R E I B I.C H >

"Intelligence is like underwear: it is important that you have it,
but showing it to the wrong people has the tendency to make them
feel uncomfortable." -- Angela Johnson

[Michel Martens]

On Wed, Aug 7, 2013 at 11:20 AM, Jay A. Kreibich <j...@kreibi.ch> wrote:
> Agreed. The key was modified; the WATCH should fail.

What's puzzling about this is that maybe a WATCH over a key with
an expire should always fail, as the change in the TTL can be
thought of as a modification. That means a key with an expire will
always be different at the time of EXEC. Of course, this may rule
out some nice use cases.

[Salvatore Sanfilippo]

On Wed, Aug 7, 2013 at 4:25 PM, Michel Martens <sov...@openredis.com> wrote:
> What's puzzling about this is that maybe a WATCH over a key with
> an expire should always fail, as the change in the TTL can be
> thought of as a modification. That means a key with an expire will
> always be different at the time of EXEC. Of course, this may rule
> out some nice use cases.

Yep, that's a bit too strict probably as the use keys "I want to make
the change only if the key still did not expired" is pretty
real-world-ness :-)

[Michel Martens]

On Wed, Aug 7, 2013 at 11:27 AM, Salvatore Sanfilippo <ant...@gmail.com> wrote:
>
> Yep, that's a bit too strict probably as the use keys "I want to make
> the change only if the key still did not expired" is pretty
> real-world-ness :-)

Yes, that would be too obsessive.

I agree, the original example should fail. Having the server
delete the key because of an EXPIRE should be treated similarly to
other client deleting the key with DEL.