Description
Following #371, I want to make a clear and simple case for supporting hset and hget within django-redis.
While I understand that this cache strives to be swappable with other cache backends, the truth of the matter is that I would wager over 50% of people using django-redis are doing so because they knew the platform they wanted to use - redis - and were simply looking for a django-compatible package for it. While I am not advocating (yet!) supporting every single redis feature, it seems curious to leave hashes out, as redis itself recommends using them whenever possible. Django is no stranger to platform-specific functionality, having database fields specific to PostgreSQL and the like.
From my experience in situations in which a library is supporting a specific back-end and expecting to be swappable with other libraries, the standard course of action is to be clear in the documentation that specific features are not available in the other back-ends and doing so would make it difficult to migrate. At that point it is up to the user if they want to lock themselves into redis, which I again wager many users would happily do, as it is the bomb :)
Why not use the native redis client?
I am coming from a use case in which I had rolled my own mini Cache class in which I was doing my own serialization (msgpack) and compression (zlib). I was happy to find a native solution I could use within my Django application, but was immediately distraught to see I'd have to use the native client for hash functionality. No worries, I thought, I'll use django-redis for non-hash stuff and do it by myself with hashes. What ends up happening then is that I have my serialization/compression functionality split into two places and if I wanted to switch I'd have to do it twice, and that point why even use django-redis at all? I very much like using something with the django ecosystem and appreciate not having to roll my own different serialization and compression functionality that I can easily swap between. I like having things like the key prefix and the versioning, as these are all things I did not have in my own custom class. So I definitely want to use django-redis, but then have to convert code to not use hashes if I don't want to be duplicating my concerns.
When the alternative is the seemingly simple path of simply allowing users like myself to use hash functions within the library at their own risk, it seems like a reasonable ask that we be allowed to do so.
I hope you will consider my suggestion.