search

jrief / django-websocket-redis

Websockets for Django applications using Redis as message queue
http://django-websocket-redis.awesto.com/
MIT License
896 stars 222 forks source link

How to store hashes and display stored hashes in the chat field. #114

Open domface opened 8 years ago

domface commented 8 years ago

The current implementation of the chatserver app allows me to write one key value pair, but after each successive input, it essentially replaces what was originally stored in that key value pair.

What i want to do is add a list of hashes to my redis DB

hmset demo:broadcast:Palo_Alto:1 username dom text helloworld type text image someurl hmset demo:broadcast:Palo_Alto:1 username steve text helloworld type text image someurl

And then when i bring up the BroadcastChatView with this data set implemented, i got a ResponseError: WRONGTYPE Operation against a key holding the wrong kind of value which i know means that redis is looking for a value but is returning a hash.

I can't seem to find in the code where i could implement what i'm trying to do here. Any thoughts?

jrief commented 8 years ago

From my point of view, there is some kind of misconception, if you use ws4redis like this. What you probably should do, is to post your data using Ajax and only use ws4redis as a downstream service (from the server to the client). There are very few use-cases where upstream makes sense. This btw. is mentioned in the docs.

domface commented 8 years ago

In which case, would i use something like Django Rest Framework and write to a relational DB like Postgres and in parallel cache to the redis datastore? Or can i write it straight to Redis?

Ideally, what I'd like to do is use redis as my primary datastore.

Apologies for all the noobish questions, but i can't seem to find the answer i'm looking for on Google.

jrief commented 8 years ago

You can write to and read from Redis directly from Django. DRF certainly is a good starting point if you have to serialize your models, but sometimes its just enough to push a Javascript object upstream and receive it downstream in another browser. That a good usecase.

Ideally, what I'd like to do is use redis as my primary datastore.

If you have not-so-valuable data, then go ahead. Redis is not very safe at persisting. If the server crashes, or on power-outage, you inevitably will lose some data. I love Redis and use it everywhere for session data, and caching. There is some documentation which handles your use case: http://django-websocket-redis.readthedocs.org/en/latest/usage.html#server-side