Feature/video relevance

[WRadoslaw]

Joystream/atlas#4071

[ignazio-bovo]

I left a question about the weights used

[ignazio-bovo]

LGTM

[ignazio-bovo]

The query looks correct, I have double checked it using chatgpt too

[Lezek123]

I had a brief look at the PR and here I some general remarks I have:

1. The PR is targetting orion-v2, but this is a stale branch. Since the production release of Orion v2, all the latest work is already on master, so please retarget your PR to master. I think we can even delete orion-v2 at this point to prevent confusion.
2. I don't think that storing the relevance score and trying to recalculate it every time some action can affect it (even if there's a "delay", like "only recalculate if views_count changes by at least X") is a good approach as opposed to extending queries using custom resolvers. It should be pretty cheap to calculate the relevance score since there are already comments_count, reactions_count and views_num columns inside video table which are kept up to date, so you don't even need to do subqueries/joins with reactions/comments/views tables in order to do that, it would just be a pretty simple formula using columns already available in video. So to clarify what I mean exactly: Instead of storing relevance score as a separate column, you could augment/create a custom query like mostViewedVideosConnection that would support ordering by relevance score and the formula for calculating the relevance score could just be part of the SELECT or ORDER BY statement, ie. SELECT (video.views_num * views_weight + video.comments_count * comments_weight ...) as relevance, what do you think? Do you see any clear downside of this approach taking into account your desired use-case?

[WRadoslaw]

How inefficient is it to keep this solution over a custom query that calculates it on the fly? When we first talked about this videoRelevance, it was supposed to be just a temporary solution until the User Accounts arrive, so then we would switch to user-targeted recommendations. Since UA development is around the corner and for now on any gateway there are not that many reactions, maybe we can keep this PR till UA-based recommendations. I hope I didn't overlook smth important here, WDYT?

[Lezek123]

How inefficient is it to keep this solution over a custom query that calculates it on the fly?

I don't think it's very inefficient, my main issue is that it's complex and more prone to errors I think.
But if it's just temporary and you're sure that it works as expected then I guess that's fine.
One suggestion I have then would be to just simplify the update query to rely on already exisiting comments_count / reactions_count counters in order not to duplicate the logic of counting those, I think that should be a pretty simple change.

[Lezek123]

Otherwise LGTM