Support for hash based data-scheme instead of prefix:username=>password

[binarybucks]

The section "data layout" of http://redis.io/topics/twitter-clone states "... what should identify a user inside our system? The username can be a good idea since it is unique, but it is also too big, and we want to stay low on memory"

As such a simple user-prefix to support scenarios of "prefix:username"=>"password-hash" is a good start but not very likely to be used.

I like an approach* of prefix:userid" => hash, where the password is stored together with every other attribute inside the hash. To get the hash for a username, I usually use a single larger hash as an index called User:uniques:name that maps a username to the id. This is a similar approach to the one recommended in the above mentioned section on the Redis site. While the principle is the same, it doesn't create at least 2*n new keys (assuming a single password attribute) for n users, but merely n+1 which don't change for more than one user attributes. I'm by no means a Redis export, but imho this feels cleaner.

Assuming, the user hash was defined HMSET User:1000 username foo password bar, and an username->id hash entry was defined with hset User:uniques:name foo 1000 the user password can be queried easily with

$uniqueid = HGET User:uniques:name testuser
HGET user:$uniqueid password

*Note: I'm a little biased, as this is the format that https://github.com/soveran/ohm is using

[jpmens]

Sounds reasonable. I'll see if I can implement this easily. At first glance I think having al the hash names configurable may be messy ...

[jpmens]

Closing for lack of interest.