Issue 473 in redis: Linking multiple keys to same value

2,083 views
Skip to first unread message

re...@googlecode.com

unread,
Feb 28, 2011, 7:28:17 AM2/28/11
to redi...@googlegroups.com
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 473 by aapo.tal...@gmail.com: Linking multiple keys to same value
http://code.google.com/p/redis/issues/detail?id=473

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.

re...@googlecode.com

unread,
Feb 28, 2011, 7:32:18 AM2/28/11
to redi...@googlegroups.com

Comment #1 on issue 473 by aapo.tal...@gmail.com: Linking multiple keys to
same value
http://code.google.com/p/redis/issues/detail?id=473

Or maybe the syntax could be like this:

SET key2 LINK key1 -> LINK key1 key2

re...@googlecode.com

unread,
Feb 28, 2011, 7:37:19 AM2/28/11
to redi...@googlegroups.com

Comment #2 on issue 473 by aapo.tal...@gmail.com: Linking multiple keys to
same value
http://code.google.com/p/redis/issues/detail?id=473

And we could even have hard links and symbolic links?

Peter Mescalchin

unread,
Mar 1, 2011, 12:06:15 AM3/1/11
to Redis DB
I have to say, and of course Salvatore can much better say on the
implantation costs/work - but this could be a VERY cool feature to
have.

On Feb 28, 11:37 pm, re...@googlecode.com wrote:
> Comment #2 on issue 473 by aapo.tal...@gmail.com: Linking multiple keys to  
> same valuehttp://code.google.com/p/redis/issues/detail?id=473

re...@googlecode.com

unread,
Mar 6, 2011, 10:55:27 AM3/6/11
to redi...@googlegroups.com
Updates:
Labels: -Type-Defect -Priority-Medium Type-Enhancement Priority-Low

Comment #3 on issue 473 by pcnoordh...@gmail.com: Linking multiple keys to
same value
http://code.google.com/p/redis/issues/detail?id=473

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.

re...@googlecode.com

unread,
Mar 11, 2011, 7:55:40 AM3/11/11
to redi...@googlegroups.com

Comment #4 on issue 473 by darkpro...@gmail.com: Linking multiple keys to
same value
http://code.google.com/p/redis/issues/detail?id=473

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).

re...@googlecode.com

unread,
Apr 14, 2011, 9:48:51 AM4/14/11
to redi...@googlegroups.com

Comment #5 on issue 473 by daniel.m...@gmail.com: Linking multiple keys to
same value
http://code.google.com/p/redis/issues/detail?id=473

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.

re...@googlecode.com

unread,
Apr 14, 2011, 10:22:19 AM4/14/11
to redi...@googlegroups.com

Comment #6 on issue 473 by catw...@archlinux.us: Linking multiple keys to
same value
http://code.google.com/p/redis/issues/detail?id=473

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.

re...@googlecode.com

unread,
Apr 4, 2013, 7:15:38 AM4/4/13
to redi...@googlegroups.com

Comment #8 on issue 473 by a.s.logv...@gmail.com: Linking multiple keys to
same value
http://code.google.com/p/redis/issues/detail?id=473

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.

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

re...@googlecode.com

unread,
Oct 24, 2013, 3:58:03 AM10/24/13
to redi...@googlegroups.com

Comment #9 on issue 473 by ayyappan...@gmail.com: Linking multiple keys to
same value
http://code.google.com/p/redis/issues/detail?id=473

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?

re...@googlecode.com

unread,
Oct 24, 2013, 2:29:05 PM10/24/13
to redi...@googlegroups.com

Comment #10 on issue 473 by josiah.c...@gmail.com: Linking multiple keys to
same value
http://code.google.com/p/redis/issues/detail?id=473

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.
Reply all
Reply to author
Forward
0 new messages