feat(patrons): update aura formula

[wJoenn]

Summary of changes and context

closes #350

Omg j'espere que ca va vous convenir parce que c'etait vraiment pas simple 😅

Todo

• Update tests

Sanity checks

• Linters pass
• Tests pass
• Related GitHub issues are linked in the description

[pil0u]

Je n'ai pas encore relu dans le détail, mais c'est du bon taf et je souligne l'effort sur les tests 💯

@Aquaj Est-ce qu'il y aura pas une astuce pour stocker l'aura en base par utilisateur ?

[Aquaj]

@Aquaj Est-ce qu'il y aura pas une astuce pour stocker l'aura en base par utilisateur ?

Bien sûr. Il y a toujours des solutions. En pratique on est presque sur un système de score à part entière, donc on pourrait très bien avoir un AuraScore qui serait calculé puis stocké via un modèle de Cache comme les autres. Mais c'est un peu plus de boulot.

Je propose d'envoyer comme ça (c'est du bon taf, le seul reproche faisable c'est justement le lieu d'implémentation de cette logique — c'est pas sa place dans le modèle, on a déjà tendance à trop y mettre de trucs), car ça implémente la bonne logique, de façon propre et testée.
Quand j'aurai un moment j'essaierai de faire un tour sur le repos et proposer des issues de refacto avec des instructions tech plus précises.

[Aquaj]

Bon taf 👍

[pil0u]

Juste pour info, le data analyste que je suis aurait écrit quelque comme ça :

with referrals as (
    select
        users.uid
        , users.username
        , referees.id as referee_id
        , count(distinct completions.id) as referee_completions
    from users as referees
    inner join users
        on referees.referrer_id = users.id
    left join completions
        on referees.id = completions.user_id
    group by 1, 2, 3
)

select
    uid
    , username
    , count(distinct referee_id) as referrals
    , ceil(100 * (
        1 * ln(count(distinct referee_id) + 1) +
        2 * ln(count(distinct case when referee_completions = 1 then referee_id end) + 1) +
        3 * ln(count(distinct case when referee_completions = 2 then referee_id end) + 1) +
        5 * ln(count(distinct case when referee_completions > 2 then referee_id end) + 1)
    )) as aura
from referrals
group by 1, 2

[wJoenn]

C'est quoi la difference ?
J'ai du mal a lire ton query mais au dela de ca, est ce qu'au niveau performance y a une difference ou c'est juste du formatage ?
Et si c'est juste du formatage, qu'est ce que tu prefere dans cette ecriture ?

[pil0u]

Sur le résultat normalement pas de différence.

Sur la lisibilité, c'est rarement une bonne pratique d'avoir des "subqueries" (requêtes imbriquées), du coup dans le milieu on préfère ce qu'on appelle les Common Table Expression, ou CTE, avec la notation with. En fonction des moteurs SQL ça peut avoir un impact sur les perfs (PostgreSQL pas à ma connaissance).

Sur les majuscules/pas majuscules, ça c'est vraiment une question de goût. Historiquement il n'y avait pas forcément de coloration syntaxique dans les éditeurs, donc l'usage des majuscules était une bonne pratique pour la lisibilité des requêtes. Par exemple je suis content qu'ActiveRecord log les requêtes avec des majuscules, vu que c'est unicolore.
Aujourd'hui, y a qu'à voir, la coloration syntaxique fait tout le taf. Les minuscules sont considérées comme une meilleure pratique, mais je considère que ça reste une question de goût.

Sur la performance, la mienne est légèrement meilleure en théorie (tu peux utiliser explain devant n'importe quelle requête pour avoir la liste des tâches séquentielles que le moteur SQL doit exécuter). Ça s'explique surtout grâce à mon inner join dès le début : je limite tout de suite mon nombre de lignes aux referees, alors que toi tu gardes tout même après l'agrégation pour ne filtrer qu'à la fin avec le having.
Avec 1000 utilisateurs, en pratique ça ne change rien. Avec 10M, ça peut faire la différence.