"draft" feature-database-redesign

[JBrown9124]

close #3

What additional changes are needed to implement this feature (we want this to be high level but thorough)?

How we GET and PUT our conversations, and POST our messages would have to be changed because currently these operations rely on the two user model. For example, we would have to find our conversations by seeing if a list of users (can be 1 to many) are participants in a conversation or by simply looking up the conversation with a conversation ID. Otheruser would have to be changed to otherUsers which would be a list of users attached to that conversation. To get a list of users for a certain conversation we would have to use the new table conversation_user (ex. convo.conversation_user) and make a list from the values returned from its Django model.
How read messages are displayed (client side) would have to be changed. For this change we would have to add functionality to show one to many avatars under a message depending on whether it is read by one to many users. A mapping of all the users that read the message to a component called ReadBy should help. This component would have Material UI’s avatar badge inside a Material UI grid.
The sidebar (client side) would have to show more users per conversation. We would add a Material UI grid in each conversation space that condenses as more users are added to the conversation. If there is only one user it would look like how it is currently.
To show a conversation as an optional social group feature, a  "add to conversation"  or “start a new conversation” prompt would have to be implemented. This could be implemented with the search for users that we currently have now (in the sidebar) by the user clicking on a user and the prompt appearing (inside the currently clicked on user box located in the sidebar) asking if they want the user (currently clicked on) to be a part of a current conversation or to start a new conversation with the user (currently clicked on).
The top area for conversations would have to show one to many user names depending on the number of users in the active conversation. A material UI grid with the usernames currently in the conversation would help.
We would have to change how messages are sent and received through socket.io because there is a possibility now that it won't be just one user receiving a message but many users. Therefore the message being emitted would be sent to multiple clients.

If our app were already deployed, what steps would we need to take to move to this new feature without disrupting service for current users?

Create unit tests for every possible situation. For example, seeing if the old structure (two users per conversation) data can be transferred correctly to our new structure (more than two users per conversation). To transfer data from the old structure to our new structure would be a timely task. Let's say we have a massive data collection of conversations. Our new database schema requires that we remove the user1 and user2 field from our conversation table. But we simply can’t do that because that would corrupt our current users data. We would have to first transfer our user1 and user2 fields data over to our new conversation_user table user field with their corresponding conversation_id. Without writing a program to do this for us, this task would take a lot of unnecessary time.
User testing is essential for making sure a new feature works properly before deploying it into our main branch. For example, we let a certain amount of users use the new feature for a certain amount of time in a separate branch while closely monitoring these user's feedback and actions to weed out potential or present bugs (open testing, closed testing, internal testing).
Once it passes testing we would maybe have to shut down the app for a certain amount of time to merge the new feature branch to the main branch or activate the feature with feature flags. Also we would have to notify the users that a patch is being implemented ahead of time while being as informative as possible. This includes creating patch notes that let the users know what changes to expect, giving users an amount of time the application may be down for and letting users know when the new changes will be in effect.

[FilipeGorodscy]

Great job!

• How would you update the Redux state to reflect the schema change?
• If we have multiple developers involved in this project, how can we split the task between them without introducing merge conflict?
• Can you simplify the proposed design if you were not concerned about backward compatibility?

Approved! But please do not merge since it's only a draft PR :)

[FilipeGorodscy]

Is this the most efficient way of storing the read status of the messages? (This is actually out of scope for this ticket, just wanted to see your answer here :))

[JBrown9124]

After closely reviewing this addition I've come to the conclusion that this isn't the most efficient way of storing the read status of the messages (looking up users who read the message with a list would not be the most efficient way). Making a separate table called MessageRead that contains a column (readAt) that stores when the user read the message, a foreign key column (message) connecting the table to Message table and a foreign key column (user) storing the user that read the message would maybe be the most efficient way.

[JBrown9124]

How would you update the Redux state to reflect the schema change?

Our state for our conversations would need to change. Instead of one otherUser there would be potentially many so we would have something like otherUser1, otherUser2, otherUser3. Creating an redux action (AddUserConversation) that calls a reducer function that adds a user to the conversation state would need to be implemented. This reducer function that this action calls upon would update the frontend of all users who are part of the conversation to the newly added otherUser state. A socket.io emit would have to be implemented as well to update the users part of the conversation states using the new reducer function. We would also have to change how messages are sent and received through socket.io because there is a possibility now that it won't be just one user receiving a message but many users. Therefore the message being emitted would be sent to multiple clients and all of these client’s states would have to be updated accordingly.

If we have multiple developers involved in this project, how can we split the task between them without introducing merge conflict?

By creating a well-defined plan with strict conventions to follow we would be able to split the task. Everyone should know what is being changed, what is remaining the same, and what they are focusing on. For example, one person or team is assigned implementing the multiple user in a conversation change of the UI. They must know the exact data they are being given from the server and redux state in order to implement these changes without merge conflict. If they are misinformed about a recent update to the data they are being given, a merge conflict occurs.