Implement all the counters
Counters are the fields used to say how many items are:
likes_count, etc. There are some of them implemented but they could be buggy or inefficient. Most of the entities can be shown in a list, ie in the community list we show the number of collections. The solution must be efficient in those case too.
Collections implement a counter using a trigger in Postgres, so they don't need to calculate the number in real time which is efficient and easier. However, the collection has to be loaded to get this number, ie: a Community has a "follower" collection which is different row in the database:
community.id != follower_collection.id
Another consideration is that many relations are not collections, ie:
Community are related using the
attributed_to property or a
A solution would be to remove those relations to create ActivityPub collections in a similar way a Community has "follower" collection. So a Community would have a "Collection collection" to store the "Collections" (naming is confusing here) or a Community would have a "Thread collection" to store all the "Threads". Another advantage of this solution is that pagination will be implemented only around collections. The main disadvantage is we have to change the database schema.
Another possible solution would be to create a custom trigger for these relations. I'm not sure it is not possible because it relates 3 different tables.
If we implement virtual fields (#74 (closed)) a possibility would be to calculate the counters in real time and set them in a virtual field. We need two different functions, one to calculate them for a single record and another for a record list. The main disadvantage is this could be an expensive query.