Alias keys

[Blake Mizerany]

Often, I find myself in situations where I need to get the same data a
few different ways

Example:

email = "foo...@foo.com"
username = "fooguy"
userdata = some_hash.to_json

# For cases when I have the username only
redis.set "user:#{username}", userdata

# For cases where I have the email only
redis.set "user:by-email:#{email}", userdata

The problem with this is 2 fold:
1. I'm duplicating data which duplicates memory consumption
2. I need to be sure to delete both keys when I delete the user

What I'm proposing is:

redis.alias "user:#{username}", "user:by-email:#{email}"

and to push my luck a little further:

redis.delete "user:#{username}" will remove all dependent aliases

I understand I can just do multiple lookups .. i.e.

username = redis.get "user:by-email:#{email}"
userdata = redis.get "user:#{username}"

but this means an extra call, which feels like clutter, and another key to track
when deletion comes around.

Is this something that is possible to get into redis? Am I insane/lazy?

--
Blake Mizerany
blake.m...@gmail.com

[Yaniv Aknin]

I see this is an ancient post, but I found it in a Google search and I think it could be relevant to me too.

(the way I'd do it is slightly different; I'd prefer deleting one alias to leave the other intact; only upon key expiry should all aliases die) 

Does this even sound like a good idea to any of the developers?

[Pieter Noordhuis]

No, this will not be implemented. You can add your own indirection
layer if you want though.

Cheers,
Pieter

> --
> You received this message because you are subscribed to the Google Groups
> "Redis DB" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/redis-db/-/TGpZqqNs-M8J.
> To post to this group, send email to redi...@googlegroups.com.
> To unsubscribe from this group, send email to
> redis-db+u...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/redis-db?hl=en.

[Yaniv Aknin]

I don't think it's important for me to argue, but I'm curious about the reasoning?

[Dvir Volk]

I'll go ahead and guess here - first of all, in terms of performance, implementing this in redis would require the server to do all this secondary key management internally, instead of on the client, and it would hurt performance for people who don't want this.

second, a lot of internals in redis assume a one to one relationship between an objects - key expiration, LRU strategies, VM swapping, replication, AOF, etc. It would require a massive rewrite of redis.

third, this would make the cluster design as it is (and external sharded clients) impossible, because several keys that point to the same data could fall into different nodes.

I'm sure there are a couple more reasons I didn't think of.

BUT - with the new Lua interface, you can actually implement this yourself on the server side.

[Yaniv Aknin]

Good reasons, really, and an interesting idea regarding the Lua interface. I'll keep this in mind, thanks!