I have a table like friends(friendship_id, fid1, fid2, ENUM('pending', 'accepted', 'ignored')
. When a user ignores someone's friend request, I want to make sure that they don't get a message saying, "You've been ignored!", but I also want that data logged. Any suggestions on how to approach this?
views:
79answers:
4Obviously the first thing you should do is to not implement any code that would display the You've been ignored!
message. This solves most of your issue.
But you have to be a little careful. There is a more subtle issue - your system should behave from the sender's viewpoint in every way as if the user hadn't clicked ignore. That means that if the sender issues a second request and normally your system says "You have already sent a request to this user" then it should continue to display this message even after the recipient has ignored the first request. You need to be careful not to leak out information by changing messages in response to an event that was supposed to be private.
Response to comments:
Do you think it's best to not even send a "You have already sent a request to this user" message in the first place?
I think this is a bit out of scope for this question and is a long discussion in itself so I will only touch upon it here. The answer depends on how your application is implemented. The short answer is: your application should help your users and be intuitive so if the message helps them then add it.
An alternative is that requests expire automatically after one week if there is no reply. Once the current request has expired you can allow the user to make a new request. You might want to consider if ignoring a request means ignoring just that one request or all requests from that user.
I've not really considered how you would distinguish who's ignoring who under my current schema.
Friendship requests are directed relationships. You have a sender and a receiver. Friendships on the other hand are usually (but not always) considered to be undirected relationships. A friendship request will usually have a message associated with it "Hey, remember me? We met in the bar last night!". On the other hand an established friendship does not typically have a message associated with it. So it might make sense to store these different types of relationship in different tables in your database.
How are you distinguishing who ignored who? If one friend ignores the other, then I suppose that ENUM
would be changed to 'ignored', and the ignored friend would also become the ignoring friend. You could tell who has ignored you, because you would appear to be ignoring them as well.
Better to put an intermediate table, like ignore(ignorer, ignoree)
, where the columns are just friend IDs. That way whenever a message, update... whatever, is sent to one friend, the app first checks whether the destination friend is ignoring the source friend.
I implemented this recently in application I'm writing. I actually had two rows in the database. My columns were sourceUserId and destUserId. When someone (person A) sends a request to another person (person B), it automatically inserts a row with A's UserId as the sourceUserId and B's UserId as the destUserId. If they send it again, it notices that the row already exists. To have B approve A, insert B's UserId as the sourceUserId and A's UserId as the destUserId.
My application also had a notification table, so each time someone adds someone else (i.e. the row with A's UserId=sourceUserId and B's UserId=destUserId is successfully inserted), a notification is sent to the destination.
To check if two people are friends, you simply check if the reciprocal rows exist.
Example: User A sent friend request to user B, user B ignored this request: User A does not know that his/her request has been ignored. To user A this request status should be seen as 'pending'.
For same 2 users: Even though user B ignored user A's request, it does not necessarily entail that user B can't try to become friends with user A. Such action should clear previous 'ignore' of user A's request (as if it never happened).
So your table schema is okay. You just have to think about the language and logic of all possible scenarios.