Linking multiple keys to same value

[GoogleCodeExporter]

It would be nice if I could have several keys pointing to _same_ value (ie. 
linking, just like in file systems).

For example:

SET key1 value
OK

SET key2 LINK key1
OK

GET key1
"value"

GET key2
"value"

SET key1 val
OK

GET key2
"val"

SET key2 value2
OK

GET key1
"val"

GET key2
"value2"

Makes a sense? This way I can use keys to build relations, but still have a one 
place to do the updates.

Original issue reported on code.google.com by aapo.tal...@gmail.com on 28 Feb 2011 at 12:28

[GoogleCodeExporter]

Or maybe the syntax could be like this:

SET key2 LINK key1 -> LINK key1 key2

Original comment by aapo.tal...@gmail.com on 28 Feb 2011 at 12:31

[GoogleCodeExporter]

And we could even have hard links and symbolic links?

Original comment by aapo.tal...@gmail.com on 28 Feb 2011 at 12:36

[GoogleCodeExporter]

It is not likely that this will be added because this would add a lot of 
complexity without (at least for me) a direct gain. Can you provide a clear use 
case where something like this is useful? Maybe there is another way to model 
it such that having links is not necessary.

Original comment by pcnoordh...@gmail.com on 6 Mar 2011 at 3:54

• Added labels: Priority-Low, Type-Enhancement
• Removed labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

It could be useful to have more than one lookup key to reference the same object
(for instance, some rather big python serialized object with two-three lookup 
keys).

Original comment by darkpro...@gmail.com on 11 Mar 2011 at 12:55

[GoogleCodeExporter]

That would be awesome. I have millions of IDs identifying strings, but there 
are just a few hundred strings. Being able to linking multiple keys to same 
value would save me a lot of space.

Original comment by daniel.m...@gmail.com on 14 Apr 2011 at 1:47

[GoogleCodeExporter]

One extra level of indirection solves this. For instance, instead of having:

key1 -> string1
key2 -> string1
key3 -> string1
key4 -> string2
key5 -> string2

You can have:

locator -> hash {
  key1 -> id1
  key2 -> id1
  key3 -> id1
  key4 -> id2
  key5 -> id2
}

s:id1 -> string1
s:id2 -> string2

I use that kind of scheme all the time. You have to make sure to use consistent 
transactions then, though.

Original comment by catwell...@gmail.com on 14 Apr 2011 at 2:21

[GoogleCodeExporter]

Indeed. This client-side scheme is obviously slower, but the added complexity 
on the server would just be too high (not to mention it would open up a can of 
issues with WATCH, persistence, etc).

Original comment by pcnoordh...@gmail.com on 22 Aug 2011 at 3:15

• Changed state: WontFix

[GoogleCodeExporter]

An interesting suggestion! I can give use case example.
I have object for item (e.g. product) that is stored in Redis. Also I need to 
find this object by some codes related to this product. For example, by UPC, 
SKU or PLU codes. So, now I store key for each code that related to product 
UID. And than I get product's object by this UID from Redis. So, it will be 
cool if I can set LINK to product's object by any of this codes.

Original comment by a.s.logv...@gmail.com on 4 Apr 2013 at 11:15

[GoogleCodeExporter]

One example - This can be effective to solve user's subscribe/unsubscribe 
problem often faced in implementing pubsub notification(over cometd) [Off 
course, there are solutions to this outside the scope of Redis, but would 
definitely help similar problem sets]. For example -
+ The events could be keyed by the event id to a complex object (possibly 
storing the last updated time stamp). This is often fewer than the number of 
users.
+ The user is keyed on the user id and subscribes to these event 
objects(reference to the actual object). The user subscription to this event 
points to the same complex object which is processed by a light weight thread 
supporting comet connection and using a last refreshed time stamp. Here, we are 
assuming no support for multi version concurrency control of the returned 
results.

Is this planned to be addressed in near future?   

Original comment by ayyappan...@gmail.com on 24 Oct 2013 at 7:57

[GoogleCodeExporter]

This enhancement was "closed wontfix" over 2 years ago, *and* this bug tracker 
is no longer being used. So no, this won't be addressed in the near future, if 
ever.

Original comment by josiah.c...@gmail.com on 24 Oct 2013 at 6:28