Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Generate stats on every request without caching them
In commit e51e034, we started using the same code to show stats in the public area and in the admin area. However, in doing so we introduced a bug, since stats in the public area are only shown after a certain part of the process has finished, meaning the stats appearing on the page never change (in theory), so it's perfectly fine to cache them. However, in the admin area stats can be accessed while the process is still ongoing, so caching the stats will lead to the wrong results being displayed. We've thought about expiring the cache when new supports or ballot lines are added; however, that means the methods calculating the stats for the supporting phase would expire when supports are added/removed but the methods calculating the stats for the voting phase would expire when ballot lines are added/removed. It gets even more complex because the `headings` method calculates stats for both the supporting and the voting phases. But, since now we're using a temporary table to calculate the stats, generating them might take between 1 and 2 seconds even in processes with a hundred thousand participants, meaning we can disable the cache and generate the stats on every request instead. It might not scale so well when there are millions of participants; we might re-enable the cache or find a different way to optimize the stats calculations if we ever get to that point. Note that, since we're only using the temporary table inside the `generate` method, we need to cache the results obtained inside this method so they're available elsewhere. We're using instance variables for this purpose. This means the code doesn't improve much with this change, but at least we don't have to worry about when we should expire the cache. Since loading stats in the admin section is fast even without the cache because they only load very basic statistics, we're not even generating them first in this case, so everything works the same way it did before commit e51e034. Co-authored-by: Javi Martín <javim@elretirao.net>
- Loading branch information