{"comment":{"url":"https://api.github.com/repos/jasonlukeball/bloccit/comments/13348916","html_url":"https://github.com/jasonlukeball/bloccit/commit/2d11d2aa5cc34710517585d7ce629503f38c5748#commitcomment-13348916","id":13348916,"user":{"login":"chikamichi","id":106689,"avatar_url":"https://avatars.githubusercontent.com/u/106689?v=3","gravatar_id":"","url":"https://api.github.com/users/chikamichi","html_url":"https://github.com/chikamichi","followers_url":"https://api.github.com/users/chikamichi/followers","following_url":"https://api.github.com/users/chikamichi/following{/other_user}","gists_url":"https://api.github.com/users/chikamichi/gists{/gist_id}","starred_url":"https://api.github.com/users/chikamichi/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/chikamichi/subscriptions","organizations_url":"https://api.github.com/users/chikamichi/orgs","repos_url":"https://api.github.com/users/chikamichi/repos","events_url":"https://api.github.com/users/chikamichi/events{/privacy}","received_events_url":"https://api.github.com/users/chikamichi/received_events","type":"User","site_admin":false},"position":34,"line":119,"path":"app/controllers/posts_controller.rb","commit_id":"2d11d2aa5cc34710517585d7ce629503f38c5748","created_at":"2015-09-21T17:55:38Z","updated_at":"2015-09-21T17:55:38Z","body":"I didn't quite pay attention to what I was saying about `update_rating` above. It's completely *not* valid, so discard it entirely.\r\n\r\nI thought twice about an `update_rating` method while I was woodworking, and actually, implementing such a method *doesn't make sense to me*.\r\n\r\nIn the checkpoint, because we had this join table *labellings* recording the relationships between models, the *labels* table (`Label` model) was there to record a list of unique labels as \"pure\" objects. Kind of a list of available labels, without duplicates. In that context, `update_rating` was there to ensure one could add a new label to that list of labels, without creating duplicates (hence the usage of `find_or_create_by`), and because it was designed so it returned the sub-list of added labels, one could assign that result to be the labels of an object; say:\r\n\r\n``` ruby\r\n# The following code line really means: \"update the list of labels with those new\r\n# labels (don't record any duplicate though), and also use them as the labels for\r\n# that @topic I'm interested in\".\r\n@topic.labels = Label.update_labels(params[:topic][:labels])\r\n```\r\n\r\nWith the ratings, we don't have a join table, so we don't have a table that's containing only a list of \"pure\" ratings. The only list we have, has duplicated ratings by design, because each one records its related models. In that context, there's no point having an `update_ratings` methods.\r\n\r\nIt lets me think that what the assignment wanted us to do, was to follow the same relationship architecture the checkpoint introduced, that is, with a join table. It's not a big deal though: you got to see how things can be done differently, and the strength and weaknesses of both.\r\n\r\nDoes it make sense?"}}