Convention de nommage

[streino]

Un peu paumé dans la convention de nommage. Je lis ici "score de avg_quality" au lieu de "moyenne de quality->score".
Au minimum, avg__quality__score ?

Originally posted by @streino in #7 (comment)

Mais j'ai l'impression qu'on ferait mieux d'utiliser la sémantique suivante :

• -> devient _. Seul hic, pas de distinction entre quality->score et un champ dont le nom d'origine serait quality_score. Mais IMO si on est confronté à ce problème le nommage original est pourri.
• __ utilisé pour séparer le nom du champ du "type" de calcul appliqué sur ce champ.
• Post-fixer le nom du champ par le type de calcul, pour regrouper lexicalement toutes les infos disponibles sur un champ.

Ce qui donnerait : nom_de_champ__calcul.
Ex : quality_score__mean, contact_point_name__exists, ...

[abulte]

J'aime quand même bien l'idée d'avoir l'info qu'on a été chercher la valeur dans un JSON nested.

Claude propose nom_de_champ__sous_champ__calcul.

[streino]

J'aime quand même bien l'idée d'avoir l'info qu'on a été chercher la valeur dans un JSON nested.

Claude propose nom_de_champ__sous_champ__calcul.

Il a pas osé le triple underscore ? 😅

Ça me pose pas particulièrement de problème, mais en quoi ça serait utile de savoir qu'on l'a récupéré dans un champ json plutôt qu'un autre champ ? Savoir où chercher dans le modèle data.gouv (mouaif, y a pas tant de nesting) ? Autre chose ?

[abulte]

Yes faire le lien avec le modèle data.gouv.fr sans avoir à trop réfléchir. C'est peut-être pas indispensable mais je trouve ça confortable.

[streino]

Ok, on part là dessus alors !
Reste à gérer la migration en essayant de conserver l'historique des métriques.

[DanFluture275]

Changements à reporter sur le dashboard également