-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Conversation
dbkr
commented
Dec 22, 2015
- Store each event that has push actions for a user & profile_tag in a table
- Pull out of that table at sync time to give the number of unread notifications
…sn't store them yet. Not very efficient.
…pdu, otherwise it will be triggered whenever we backfill too.
…ion required: much as it would be nice to be able to tell between the event not having been processed and there being no notification for it, this isn't worth filling up the table with ['dont_notify'] I think. Consequently treat the empty actions array as dont_notify and filter dont_notify out of the result.
…object on sync (only actually corrrect in a full sync: hardcoded to 0 in incremental syncs).
… incremental syncs too, where necessary, and fix silly bugs like only select the event actions for that user...
… by one, but does far fewer db queries to fetch the rules
@@ -0,0 +1,98 @@ | |||
# -*- coding: utf-8 -*- | |||
# Copyright 2014 OpenMarket Ltd |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Copyright year should be 2015
ptal |
Another thought: should I be running the event through _filter_events_for_client? If so, what would be an efficient way to do this given this function seems to do a db hit to fetch the state? |
I tried running sytest using postgres and got an error:
|
We probably do want to run the event through _filter_events_for_client. If we already have a copy of the state then we should probably use that rather than requesting a new copy for each user in the room. |
… or not. Use this so we can run _filter_events_for_client when calculating event_push_actions.
…uid -> password hash
ptal. This, I believe, correctly runs _filter... (and also processes redactions correctly). The former means more db queries since we need to fetch state and whether users are guests. These are ripe for optimisation but unsure whether doing so up front would be premature. |
LGTM other than the potential fun for guest users since they can't set read receipts. |
Good point. With this code, guest users will just never be able to clear their notifications I think. If we plan to continue not allowing guest users to send read receipts, I'll have to work around this somehow. |
Conclusion is that we need to see read receipts from guests anyway, so no need for us to work around this. However this means we're probably blocked behind guest RRs being enabled. |
I'm happy for this to land, since the guest access is orthogonal. It's not like the clients have to read the notification count fields. |
This is a very good point. |