Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Ok, I added conversations!
I rejigged the architecture a bit from the hackathon. First I'll define a few concepts:
The relationship between Conversation and is now a GenericForeignKey on the Conversation. You can include ConversationMixin into some other model which will give you
The previous implementation I did at the hackathon would populate ChannelGroups for all of a users conversations when they connected. But I decided it doesn't seem necessary to do so much stuff, most of the users will not do much, and most of the conversations will remain empty (remember a "conversation" might end up being on many many things - there could be a lot).
So for the connection flow (implemented in the
Then the bridge between conversations and subscriptions (currently in subscriptions/receivers, but arguably should be slightly abstracted and put under conversations/receivers):
Then, for the conversations part (pretty simple);
Then, Group is the only model that has a conversation now and has to obey the contract to handle the logic for how to add/remove participants from the conversation. In this case kind of simple, as if you are in the group you should be in the conversation. it's handled with signals in groups/receivers.
Currently it includes the logic about creating/deleting the conversation too, but I'd like to add that into ConversationMixin too. But not right now.
I added tests for about half of it so far (has a nice way of handling the websocket tests, was very nice! - https://channels.readthedocs.io/en/stable/testing.html).
You can try it out too!
Adding this subscriptions concept actually means if you want to send other stuff to the users browsers you can - would have to flesh it out a bit more, but it would support a concept where users are subscribed to changes to the current item they are on (e.g. a store page), and can get notified when things happen (e.g. "store updated" - with some payload data, or trigger a reload etc...).
Ok, thats enough words for now :)
@@ Coverage Diff @@ ## master #333 +/- ## ========================================== + Coverage 97.89% 98.21% +0.32% ========================================== Files 140 153 +13 Lines 3891 4157 +266 Branches 174 181 +7 ========================================== + Hits 3809 4083 +274 + Misses 63 54 -9 - Partials 19 20 +1
Just a bit more detail on the reason I stopped using the ChannelGroup - as they are actually pretty nice, it delegates the actual sending to all the subscribers to redis (or other backends) instead of sending out multiple messages from the backend.
... the problem is managing the adding and removing of users to and from groups. As conversations are designed to be lightweight and added to almost anything there is likely to be a much larger number of things to receive messages about compared to the number of connected users).
If each of the things you might receive a message about had a channel group, it makes sending the updates easy (
So the answer here is to store a very broad user intention in the ChannelSubscription table (currently just "I am a connected user and I might want to receive some stuff"), and then choose who should receive messages when the event itself happens (e.g. a new message). Having it in the database also means it's available to do db joins on to limit the results to connected users. With ChannelGroups it's not possible (afaik) to easily get a list of the users in a group anyway.
I'm mostly writing this stuff whilst it's in my mind, should probably transfer it to a documentation area.
This was referenced
Aug 6, 2017
@tiltec hmm odd, it's not very different from normal manage.py now, see https://github.com/yunity/foodsaving-backend/pull/333/files#diff-632b651e5579af0e928ed63482e9bc77R7
if 'test' in sys.argv: os.environ.setdefault("DJANGO_SETTINGS_MODULE", "config.test_settings") else: os.environ.setdefault("DJANGO_SETTINGS_MODULE", "config.settings")
If I run manage.py with test_settings then it doesn't even start:
I can't see how the version of manage.py in master is executing anything differently from the one in here (unless running the test command).
Yup. It works here and works on CI. You're right they could be in a seperate PR. I could do that later today probably.…
On 9 Aug 2017 00:59, "Tilmann Becker" ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In config/test_settings.py <#333 (comment)> : > @@ -0,0 +1,34 @@ +# Start with the regular settings + +# Speeds up test execution. +# See https://brobin.me/blog/2016/08/7-ways-to-speed-up-your-django-test-suite/ + +# noinspection PyUnresolvedReferences +from .settings import * # noqa: F401,F403 Just saw this. Well then it should theoretically work, as it also loads local_settings. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#333 (review)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAB7gGmX2PQjW2ny6HFBSqW0q8he1i6wks5sWOhrgaJpZM4OujfE> .