-
-
Notifications
You must be signed in to change notification settings - Fork 428
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support redis hashes in the API #373
Comments
After a thinking a bit on this I'm open to see a PR with that and merge it ;) |
I agree with @pbysh. |
@pbysh can you share your implementation and maybe submit a PR? |
This comment has been minimized.
This comment has been minimized.
#598 seems to be a duplicate of this. And yes, a very needed feature. |
Did not test any of this code but hopefully it helps someone make a PR. To support Redis hashes in django-redis, you'll need to update the Django cache backend to include the new hash methods. You can do this by extending the DefaultClient class in django_redis/client/default.py and adding the new methods for hset, hdel, hlen, hkeys, and hexists. Then, update the RedisCache class in django_redis/cache.py to use the new client with hash support. Here's an example of how you can implement this:
Now you should be able to use Redis hashes with Django cache:
To support Redis hashes in the Django-Redis API, you can add the following methods to the django_redis.client.DefaultClient class:
To add an interface similar to Redis-Py for hashes, you can also create a new class that extends the django_redis.client.DefaultDict class and adds methods for the various Redis hash operations. Here is an example implementation:
This RedisHash class extends the DefaultClient class and adds methods for the Redis hash operations such as hset, hget, hmset, hmget, and hgetall. It serializes and deserializes the values into JSON format using the json.dumps and json.loads functions. You can use this RedisHash class wherever you use the Django-Redis API and need to interact with Redis hash data. For example:
|
thanks @some1ataplace but |
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.
The text was updated successfully, but these errors were encountered: