LemmyNet / lemmy

🐀 A link aggregator and forum for the fediverse
https://join-lemmy.org
GNU Affero General Public License v3.0
13.17k stars 872 forks source link

Move site_aggregates to local_site_aggregates #3733

Open dessalines opened 1 year ago

dessalines commented 1 year ago

Requirements

Is your proposal related to a problem?

Currently, site_aggregates updates are being triggered for every remote site update. Since this table should only hold aggregates for your local_site anyway , not remote sites, it should be reworked to join of of local_site.

Describe the solution you'd like.

Change site_aggregates to local_site_aggregates

Describe alternatives you've considered.

na

Additional context

3732

phiresky commented 1 year ago

With the current state this would be the clean way, but wouldn't it make sense to start keeping track of other site aggregates as well? (mid-term). I think https://join-lemmy.org/instances is basically the same thing as https://lemmy.world/communities except for sites not communities and missing the stats

Not saying it should be added now, but having site_aggregates have the same structure as community_aggregates and person_aggregates makes sense to me.

RocketDerp commented 1 year ago

wouldn't it make sense to start keeping track of other site aggregates as well?

For remote communities, remote instances, and remote persons - it makes sense to replicate their profile like lemmy_server does already for community and person. The one single row of their aggregate could be sent just like edits to a community from home instance are sent, or like how edits to a person profile are sent. Every 1 hour, 4 hours, 12 hours for site_aggregates row - something like that as a server tuning parameter.

dessalines commented 11 months ago

Site aggregates just has counts for things like users, posts, active_week, etc. I don't think that info really needs to be federated.

cc @Nutomic

Nutomic commented 11 months ago

What phiresky says makes sense, if we calculate aggregates for remote persons and communities, why not for sites too? But based on the way site aggregates is currently used (only single entry for local site), it would make sense to rename it and refer to local_site_id instead of site_id. So Im not sure, both sound reasonable.