{"action":"created","issue":{"url":"https://api.github.com/repos/WordPoints/hooks-api/issues/55","labels_url":"https://api.github.com/repos/WordPoints/hooks-api/issues/55/labels{/name}","comments_url":"https://api.github.com/repos/WordPoints/hooks-api/issues/55/comments","events_url":"https://api.github.com/repos/WordPoints/hooks-api/issues/55/events","html_url":"https://github.com/WordPoints/hooks-api/issues/55","id":122520747,"number":55,"title":"Log all hits","user":{"login":"JDGrimes","id":4005415,"avatar_url":"https://avatars.githubusercontent.com/u/4005415?v=3","gravatar_id":"","url":"https://api.github.com/users/JDGrimes","html_url":"https://github.com/JDGrimes","followers_url":"https://api.github.com/users/JDGrimes/followers","following_url":"https://api.github.com/users/JDGrimes/following{/other_user}","gists_url":"https://api.github.com/users/JDGrimes/gists{/gist_id}","starred_url":"https://api.github.com/users/JDGrimes/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/JDGrimes/subscriptions","organizations_url":"https://api.github.com/users/JDGrimes/orgs","repos_url":"https://api.github.com/users/JDGrimes/repos","events_url":"https://api.github.com/users/JDGrimes/events{/privacy}","received_events_url":"https://api.github.com/users/JDGrimes/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/WordPoints/hooks-api/labels/question","name":"question","color":"cc317c"}],"state":"open","locked":false,"assignee":null,"milestone":{"url":"https://api.github.com/repos/WordPoints/hooks-api/milestones/1","html_url":"https://github.com/WordPoints/hooks-api/milestones/0.1.0","labels_url":"https://api.github.com/repos/WordPoints/hooks-api/milestones/1/labels","id":1336105,"number":1,"title":"0.1.0","description":null,"creator":{"login":"JDGrimes","id":4005415,"avatar_url":"https://avatars.githubusercontent.com/u/4005415?v=3","gravatar_id":"","url":"https://api.github.com/users/JDGrimes","html_url":"https://github.com/JDGrimes","followers_url":"https://api.github.com/users/JDGrimes/followers","following_url":"https://api.github.com/users/JDGrimes/following{/other_user}","gists_url":"https://api.github.com/users/JDGrimes/gists{/gist_id}","starred_url":"https://api.github.com/users/JDGrimes/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/JDGrimes/subscriptions","organizations_url":"https://api.github.com/users/JDGrimes/orgs","repos_url":"https://api.github.com/users/JDGrimes/repos","events_url":"https://api.github.com/users/JDGrimes/events{/privacy}","received_events_url":"https://api.github.com/users/JDGrimes/received_events","type":"User","site_admin":false},"open_issues":17,"closed_issues":23,"state":"open","created_at":"2015-10-03T13:42:16Z","updated_at":"2015-12-16T14:52:22Z","due_on":null,"closed_at":null},"comments":2,"created_at":"2015-12-16T14:52:22Z","updated_at":"2015-12-16T21:45:13Z","closed_at":null,"body":"## Background\r\n\r\nAfter some work on #53 and #10, I'm wondering whether we might be able to solve a range of problems by logging every fire, or every hit, to the database.\r\n\r\n### Points Reactor\r\n\r\nThis would help the points reactor by providing a way for us to determine whether to actually award points for a hit, by calculating the number of hits for that entity and the number of reverses. See #53.\r\n\r\n### Periods Extension\r\n\r\nThis would help the periods extension in a variety of ways, for both absolute and relative periods. For absolute periods, knowing the last time that an event fired (hit actually) is important for properly adjusting things when the time length for a period is increased or decreased. It is also important to know the time of the last hit for relative periods, since period length is calculated from the last hit.\r\n\r\nIt is also important that we be able to identify whether the original even occurred during the current period, when reversals occur.\r\n\r\n## Questions\r\n\r\nThis seems to me to be a good idea, because it solves a variety of problems in one fell swoop. However, there are definitely some open questions that we'll need to explore.\r\n\r\n### Retroactive API\r\n\r\nHow would this interact with the retroactive API?\r\n\r\nIn some ways, this API would be doing the same thing as the retroactive API; that is, it would be solving some issues that I was planning for the retroactive API to one day solve. However, I'm not really sure that the retroactive API was really the best solution for those things anyway, so I think it is a good thing for us to entertain this alternative possibility.\r\n\r\nOne example of where we would maybe use the retroactive API is in helping to handle edge-cases when the length of a period changes. The problem with that idea is that while the retroactive API can tell us whether an event has taken place, it can't tell us *when* that event has taken place. So the only way that we would find it useful is if we performed the query each time a period started. That would be expensive, especially since these queries are uncached and can become rather complex. So this solution is much better.\r\n\r\nThe query API would not be helpful for the points reactor either. What we need to know there is not just whether an event has happened, but whether a hit was made, and the retroactive/query API cannot help us there. Also, the status of a post, for example, will have already been updated in the database before the hit occurs, so running a query at that point is useless.\r\n\r\nI question whether even the hypothetical badges reactor would benefit from the query API. I suppose it would depend upon whether we make badges stateful or cumulative. If we make them stateful then the query API would be invaluable. But we'd need something like this proposal if we wanted to make them cumulative (or stateful with a one-way valve, I think).\r\n\r\n### Fires, Hits, or Misses\r\n\r\nAnother important question is whether we would want to log all fires including misses, or only hits.\r\n\r\nLogging misses, you understand, will cause the logs to accumulate at a rapid pace. So it is something that we'd like to avoid, if possible. However, I'm wondering if there may be some times where we need to log misses. So let's consider our use cases.\r\n\r\nFor the points reactor there is no need to log misses, only hits.\r\n\r\nFor the periods extension it is the same story. One thing that we need to know is whether past hits happened during the current period when a period's length is increased. When reversals occur, we need to know whether the original event that is being reversed actually caused a hit. To know that we'd just need to be able to check for a matching hit for that event in the database; if we didn't find one we could safely assume it was a miss then. So there would be no need to have the misses themselves logged for that purpose. However, I'm wondering whether it really is sufficient when, for example, a post's status is toggled multiple times. With the points reactor it doesn't matter, because it will not be reversing that event (it only listens for spam and posts don't have a spam status by default), but what about other reactors that do listen for reversals (or other events that do cause spam hits)? The reversal is going to be logged no matter what if it hits, so I guess there's no problem there. We'd hit the target, the period would start. The hit would be reversed, the original hit would no longer count for that period. Whether the target actually listens to reversals is irrelevant.\r\n\r\n## Benefits\r\n\r\nIt would allow us to fire the reversal and spam actions only when a hit had actually occurred. I'm not entirely sure that we'd want to hard-code that into the API, because possibly there could be reactors that only want to listen to spam events, for example."},"comment":{"url":"https://api.github.com/repos/WordPoints/hooks-api/issues/comments/165258911","html_url":"https://github.com/WordPoints/hooks-api/issues/55#issuecomment-165258911","issue_url":"https://api.github.com/repos/WordPoints/hooks-api/issues/55","id":165258911,"user":{"login":"JDGrimes","id":4005415,"avatar_url":"https://avatars.githubusercontent.com/u/4005415?v=3","gravatar_id":"","url":"https://api.github.com/users/JDGrimes","html_url":"https://github.com/JDGrimes","followers_url":"https://api.github.com/users/JDGrimes/followers","following_url":"https://api.github.com/users/JDGrimes/following{/other_user}","gists_url":"https://api.github.com/users/JDGrimes/gists{/gist_id}","starred_url":"https://api.github.com/users/JDGrimes/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/JDGrimes/subscriptions","organizations_url":"https://api.github.com/users/JDGrimes/orgs","repos_url":"https://api.github.com/users/JDGrimes/repos","events_url":"https://api.github.com/users/JDGrimes/events{/privacy}","received_events_url":"https://api.github.com/users/JDGrimes/received_events","type":"User","site_admin":false},"created_at":"2015-12-16T21:45:13Z","updated_at":"2015-12-16T21:45:13Z","body":"I knew that there was some scenario that might make us want to log misses, but I couldn't remember what it was. Now I do:\r\n\r\nUser publishes a post, receives points, period begins. They publish another post, period hasn't ended, they receive no points. The period ends, they go back and unpublish the post, then publish it again. They receive points.\r\n\r\nDo we care? Most of the time users don't have the ability to toggle the post's visibility like that unless they are in a more highly trusted role. More generally, the rate limit still keeps the user from earning more than the set rate of points, so it does its job."}}