Add "key operation" methods to KeyBound and *Operations interfaces [DATAREDIS-48]

[spring-projects-issues]

Lasse opened DATAREDIS-48 and commented

It would be nice if the following key operations from RedisCommand are also available in the KeyBound interface (operating on the bound key) and in the ValueOperations/HashOperations/ListOperations/SetOperations/ValueOperations/ZSetOperations interfaces (with key as argument, probably introduce a new interface here):

del, exists, expire, expireAt, persist, ttl, type

This would make the code more fluent to write

---

Affects: 1.0.0.M2

Sub-tasks:

• DATAREDIS-67 make rename/renameIfAbsent lenient when the key does not exist

[spring-projects-issues]

Costin Leau commented

I can see the usefulness of such methods for keyed components but not for generic operations (like ZSet/Set). You can already do this by calling getOperations() (available on each XXXOperation). It's one extra method but it gives access to all the other views w/o having to overload the interfaces. Plus besides expire & expireAt, most other operations are not usual or do not make sense (you know you are talking to a String/Value so no reason to call type).

Maybe I'm missing something - do you have some pseudo-code for this case?

[spring-projects-issues]

Costin Leau commented

See the trunk - KeyBound has been renamed (for consistency) to BoundKeyOperations and exposes several new methods. Feedback is more then welcome

[spring-projects-issues]

Lasse commented

Thanks for adding the methods to BoundKeyOperations. You did not add a key-bound DEL, why is that? I guess one could argue that removing something key-bound is a little bit weird, but then again you can SET it even if it does not exist. I very much like the key-bound ops and think they should support whatever is possible.

As for the non-bound operations: I get your point and I overlooked getOperations(), so yes, that's okay as is. :)

[spring-projects-issues]

Costin Leau commented

I'm still on the fence with delete based on the trouble I had with rename. Since the operation is bound to a key, deleting the key doesn't make a lot of sense from the functional POV. Redis supports this but I'm not sure what this means to all the implementations out there of this interface (such as AtomicInteger or AtomicLong - w/o a key what's the default value?). Maybe a different interface for read-only access would need to be created... Not yet sure

[spring-projects-issues]

Lasse commented

I share your concerns about key-bound delete, let's just leave it out.

In fact, I actually think that key-bound rename may probably not be a good thing as well, since I think that the key-binding should be "final", so that once you get a key-bound object, it will always be bound to the same key. Might lead to strange errors otherwise

[spring-projects-issues]

Costin Leau commented

Hi,

I've pushed the latest code to github. The mutative operations are there except renameIfAbsent and move simply because if the connection is pipelined or in multi/exec mode, it's impossible to know the outcome of the operation. This creates some strange implications so rather then adding something rarely useful I decided to just remove it completely (we can always add it in).

Try it out and let me know how it goes - I'll be away next week but I plan to cut M3 shortly after I return.

Cheers,