remove update-release-activity background job and calculate the release-activity on the fly

[syphar]

the previous solution in update_release_activity used 60 separate queries.

We can easily replace this with a materialized view while also extending the range to all of history (refreshing the view takes ~200ms currently). This would enable us also to extend the time being shown, if we wanted to.

Another alternative approach could be to drop the background job completely (simplifying is always nice), and use a simple query with GROUP.
This would runs in ~15ms (compared to the <1ms for the query based on the materialized view).

When there is a decision on which way to go I would also add some more tests.

[syphar]

Just saw there is one small bug, will fix it

[jyn514]

Another alternative approach could be to drop the background job completely (simplifying is always nice), and use a simple query with GROUP.

Can you expand on this more? It sounds nice, I'd prefer the simpler solution where possible.

[syphar]

Another alternative approach could be to drop the background job completely (simplifying is always nice), and use a simple query with GROUP.

Can you expand on this more? It sounds nice, I'd prefer the simpler solution where possible.

@jyn514

• remove the cronjob
• remove the release_activity_updater
• let the view directly run a single query (with date-filters, and GROUP BY).

Which definitely simplifies the code, but it adds ~15-20ms to the view (which could be fine for a view that isn't used that much)

[syphar]

@jyn514 I just did the simplifying change as I would see it.

If that's not what we want, I can just revert the commit.

[jyn514]

This looks really good. I like calculating the info on demand instead of having the cronjob.

[syphar]

@jyn514 I changed it to using the int-cast, also I extended the test a little.

[jyn514]

This is great! Thank you!