Gestion des métaInformations

Lorsqu'un utilisateur est exposé pour la 1e fois à une graphie, dans notre cas cela sera lorsque la graphie est présente dans un des lexiques de l'utilisateur, créer les 3 templates de MétaInformations suivants :

• Passer la valeur à "connu" sur choix de l'utilisateur (clic sur la tickbox à cet effet dans l'interface d'un lexique)

{
  "description": "Statut d'apprentissage",
  "category": "string",
  "default": "non connu",
  "choices": [
    "connu",
    "non connu"
  ]
}

• Incrémenter de 1 lorsqu'une entrée correspondant à la graphie est crée dans un lexique.
  Décrémenter ... supprimée ...

{
  "description": "Nombre d'entrées lexicales",
  "category": "integer",
  "default": "1"
}

• Incrémenter de 1 lorsqu'une entrée correspondant à la graphie est modifiée PAR CET UTILISATEUR dans un lexique.
  Décrémenter lorsque une entrée modifiée par lui est supprimée ...

{
  "description": "Nombre d'entrées lexicales personnalisées",
  "category": "integer",
  "default": "0"
}

added Olala label

changed the description

changed title from Détails divers to Gestion des métaInformations

mentioned in issue #87 (closed)

added Spring fever label and removed Olala label

changed the description

@esimonnet MetaInfos : dans la plupart des cas est-ce qu'il ne faut pas plutôt modifier le modèle de données pour stocker les infos qui permettront de calculer les metaInfos plutôt que de stocker des valeurs à incrémenter/décrémenter ?

◦ Nb d’entrées lexicales liées à une graphie : info déjà récupérable

◦ Nb d’entrées modifiées par utilisateur : calculable à partir des logs si on stocke user_id et entry_id dans les logs

◦ Statut "Connu" : on peut créer une entité qui lie user et entry sur laquelle on pourra stocker cette info et d’autres plus tard ?

Tu as raison, les valeurs des métainfos seront systématiquement calculables en faisant une recherche dans les logs. Je pense qu'on peut choisir entre les deux méthodes celle qui est la plus facile à mettre en place :

• stocker une "règle de calcul" à partir des logs (est-ce que ça ne sera pas inutilement lourd en calcul dans un futur où un utilisateur aurait des années d'activité en logs à son actif ?)
• faire un appel à updateMeta à chaque fois qu'une action affectant la valeur d'une métainfo est effectuée et stocker l'info

C'est possible que la table de logs grandisse beaucoup avec les années mais ce sera problématique dans tous les cas de figure car on a besoin des logs pour mettre à jour les méta-infos.

Par ex, si on garde la métainfo pour calculer le "Nb d’entrées modifiées par utilisateur", quand un utilisateur supprime une entrée il faudra regarder tous les logs liés à l'entrée pour savoir qui l'avait modifiée et pour chacun d'eux aller décrémenter la métainfo correspondante. Un traitement complexe pour pas grand chose.

Le calcul en temps réel est forcément beaucoup plus simple. Mais c'est vrai que si la métainfo doit être affichée à chaque chargement de page, ça peut-être pertinent de stocker l'info plutôt que de la calculer. À voir au cas par cas je dirais. Ou aller au plus simple pour l'instant et laisser les pbs potentiels pour plus tard ?

Allons au plus simple oui. De toutes façons, pour les 3 métaInfos prévues :

• pour la 1e l'info existe donc la question en se pose pas
• pour la 2nde, stockons la règle de calcul uniquement
• le statut "connu" est en effet un peu particulier, créer une entité pour faire le lien ça me parait bien, en revanche le lien sera entre user et headword afin qu'un headword marqué comme "connu" dans un lexique soit également automatiquement passé à "connu" dans un autre.

changed milestone to %Version 2 (UX + retours)