Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Separate table/model for friendship blocking records #12

Open
sungwoncho opened this issue Dec 5, 2015 · 8 comments
Open

Separate table/model for friendship blocking records #12

sungwoncho opened this issue Dec 5, 2015 · 8 comments

Comments

@sungwoncho
Copy link
Collaborator

friendship table contains too much information, it would be nice if some of them are decoupled.

I think it'd be a good idea to make a separate table/model for records for friendship block/unblock, with blocker_id and blockee_id.

@Pensarfeo
Copy link
Collaborator

If we have a blocker_id we don't need a blockee_id. We could also just add a "blocked" and "bocked_by" status; according to whom blocked the relation.

@sungwoncho
Copy link
Collaborator Author

You're right. We don't need both blocker_id and blockee_id. Plus, they sound funny. Maybe the new table blocked_friendships could have friendship_id foreign key and blocker_id, and blocker_type to make the polymorphic association complete.

@Pensarfeo
Copy link
Collaborator

I have been thinking about it and it seems more logical to me to keep the same convention you used for the friendship request. That way we keep the table cleaner. I think we should add some validations too

@sungwoncho
Copy link
Collaborator Author

What convention do you mean? Do you mean that we keep the current structure?

@Pensarfeo
Copy link
Collaborator

Just like for a request we have "requested" and "pending", we can do the same for blocked records: for example we can have "blocked" and "blocked_by"

@sungwoncho
Copy link
Collaborator Author

That's a reasonable approach. We could add statuses like was_blocked and did_block. I think this is not an urgent feature because current setup works just fine. This is something to consider in the future improvement. Let's sit on it and wait for more input from the others.

@sungwoncho
Copy link
Collaborator Author

By the way your PR was very helpful. Would you like to be a collaborator for this gem?

@Pensarfeo
Copy link
Collaborator

Sure:) It would be fun to keep collaborating in this project

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants