Add a column participant to room_memberships table
#18068
Conversation
H-Shay
changed the title
participant to room_membership tableparticipant to room_memberships table
|
Requesting @anoadragon453's feedback on this as he has context. |
| @@ -1440,6 +1440,9 @@ async def handle_new_client_event( | |||
| ) | |||
| return prev_event | |||
|
|
|||
| if event.type == "m.room.message": | |||
There was a problem hiding this comment.
Drive by comment: presumably we also want to include encrypted messages here? Which have their own event type?
There was a problem hiding this comment.
Good point! Thanks for picking up on that :)
| AND rm.membership = 'join' | ||
| AND e.type = 'm.room.message' | ||
| AND rm.user_id = e.sender; | ||
| """ |
There was a problem hiding this comment.
Double checking the logic, on this, the original query was written using current_state_events so that only current room members would be included - however, won't changing to using room_memberships pull anyone who has ever posted, regardless if they have left the room?
Since the suggestion to use room_memberships originated in a performance concern, which should be alleviated by this being a background update, can I switch back to the query using current_state_events? Original discussion here: #18040 (comment)
There was a problem hiding this comment.
@H-Shay wouldn't limiting rows by the membership column of room_memberships to join values exclude users who have left the room?
Adds a column
participanttoroom_membershipstable to track whether a user has participated in a room - participation is defined as having sent am.room.messageevent into the room.Related to #18040, the approach there to determine room participation was deemed too inefficient and adding this column was the recommend remedy.