Comment 1 for bug 708841

Just noting that I'm not sure whether we're talking about a feature or a bug here. That is, we wanted to ensure that the views behind the stats URLs would only ever be hit when their cache timed out (very heavily cached).

It obviously looks wrong when the example stats only contain one package, but when it contains 10k we can't be clearing the cache for this url each time a review is flagged.

It was because this request will potentially be so heavy on the server that we enabled tho /review-stats/last-[1,3,7]-days/ urls, on the assumption that clients would be requesting updated stats at *most* once-per-day.

From memory, we had a conversation along the lines of the USC client updating its local copy for individual packages when the user adds a review, or flags a review etc. (so at least their own modifications look consistent).

{{{
12:16 * noodles is confused about the stats bug - I thought the whole point was that url should be very heavily cached?
12:17 < noodles> (ie. the cache for the stats should not be cleared every time a moderation is flagged etc.)
12:25 < achuni> noodles: right, but even after cache has expired, stats never go away
12:26 * achuni checks the stats bug
12:27 < achuni> yup
12:27 < noodles> Oh? OK.
12:28 < achuni> noodles: ie, flagging a stat should decrease the stats for the software item (or moderating the flag, at the latest)
12:29 < noodles> achuni: flagging a review? I don't see how that's possible while heavily caching that url (as the client downloads *complete* stats)
12:29 < noodles> (ie. we wanted to be able to write the file out regularly and just server the static file, from memory)
}}}