{"action":"created","issue":{"url":"https://api.github.com/repos/propershark/shark/issues/12","repository_url":"https://api.github.com/repos/propershark/shark","labels_url":"https://api.github.com/repos/propershark/shark/issues/12/labels{/name}","comments_url":"https://api.github.com/repos/propershark/shark/issues/12/comments","events_url":"https://api.github.com/repos/propershark/shark/issues/12/events","html_url":"https://github.com/propershark/shark/issues/12","id":168798039,"number":12,"title":"Redundant station list on routes?","user":{"login":"elliottwilliams","id":910198,"avatar_url":"https://avatars.githubusercontent.com/u/910198?v=3","gravatar_id":"","url":"https://api.github.com/users/elliottwilliams","html_url":"https://github.com/elliottwilliams","followers_url":"https://api.github.com/users/elliottwilliams/followers","following_url":"https://api.github.com/users/elliottwilliams/following{/other_user}","gists_url":"https://api.github.com/users/elliottwilliams/gists{/gist_id}","starred_url":"https://api.github.com/users/elliottwilliams/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/elliottwilliams/subscriptions","organizations_url":"https://api.github.com/users/elliottwilliams/orgs","repos_url":"https://api.github.com/users/elliottwilliams/repos","events_url":"https://api.github.com/users/elliottwilliams/events{/privacy}","received_events_url":"https://api.github.com/users/elliottwilliams/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":1,"created_at":"2016-08-02T04:41:42Z","updated_at":"2016-08-02T05:06:28Z","closed_at":null,"body":"A list of stations is included on routes (`route.stations`), and each station seems to be associated to its route (`route.associated_objects[\"Shark::Station\"]`). Should one of these be dropped? And which list should I use?\r\n\r\nSee https://gist.github.com/elliottwilliams/a676a83fef3ecf9fa9443543f87ee590 for an example serialized route object."},"comment":{"url":"https://api.github.com/repos/propershark/shark/issues/comments/236799353","html_url":"https://github.com/propershark/shark/issues/12#issuecomment-236799353","issue_url":"https://api.github.com/repos/propershark/shark/issues/12","id":236799353,"user":{"login":"faultyserver","id":783733,"avatar_url":"https://avatars.githubusercontent.com/u/783733?v=3","gravatar_id":"","url":"https://api.github.com/users/faultyserver","html_url":"https://github.com/faultyserver","followers_url":"https://api.github.com/users/faultyserver/followers","following_url":"https://api.github.com/users/faultyserver/following{/other_user}","gists_url":"https://api.github.com/users/faultyserver/gists{/gist_id}","starred_url":"https://api.github.com/users/faultyserver/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/faultyserver/subscriptions","organizations_url":"https://api.github.com/users/faultyserver/orgs","repos_url":"https://api.github.com/users/faultyserver/repos","events_url":"https://api.github.com/users/faultyserver/events{/privacy}","received_events_url":"https://api.github.com/users/faultyserver/received_events","type":"User","site_admin":false},"created_at":"2016-08-02T05:06:28Z","updated_at":"2016-08-02T05:06:28Z","body":"I think we discussed this a little bit a few days ago, and from what I remember, we couldn't really come to a decision.\r\n\r\n`route.stations` should definitely be kept, since it provides the station order (`associated_objects` is not an *ordered* set). So, the question is really \"should a route have associations to all of the stations it touches?\".\r\n\r\nObviously, it's easiest to just leave it in (since it already works that way), but removing the duplication wouldn't be too difficult either.\r\n\r\nHere's a pros/cons that I can see:\r\n\r\nPros:\r\n- `associated_objects`, as a Set, is guaranteed to be a set of unique stations that a Route touches. This means that clients can avoid reading large (potentially 1000+ element) lists of stops that contain many duplicates (think small loops like Inner Loop or Ross Ade).\r\n- Depending on the view, `associated_objects` can generically be used as \"the set of topics to subscribe to\" without any special logic for routes saying \"for stations, use route.stations instead\". This would also hit the first issue, where duplicate stations would be iterated whenever a route loops.\r\n- Keeping the association simplifies the management of back-associations that stations have to the routes that pass through them. Since this information is updated through a route `update`/`activate` event, it is simplest to iterate the `associated_objects` during that event to dissociate removed stations and then add new ones (really, this is done by removing all associations and adding all of the new ones).\r\n\r\nCons:\r\n- Data duplication is obviously useless. On large routes (that don't loop often), you could easily have 50+ station objects duplicated.\r\n- The list doesn't provide much semantic information, Since order is not guaranteed, `associated_objects` can't be used to define the loop that a route follows (which, sans-duplicates, `route.stations` could), so the only information gained is the unique list of stations, which can be easily and quickly computed by the client.\r\n\r\n\r\nPro #3 is my primary rationale for keeping it. I also don't want to have special logic that masks attributes on events (though, that could be a separate middleware...hmmm), especially since this seems to be the only case for such logic right now.\r\n\r\nMy list isn't at all exhaustive. If you have any other pros/cons, feel free to add them. I honestly don't know much about how the client works/the nuances of using the information I'm publishing, so I wouldn't be surprised if there are things that I've missed."}}
{"actor":{"display_login":"faultyserver"}}