Optimisation du stockage des avis - configuration des nouvelles tables

[lucaa]

La plateforme XWiki dispose d'un mécanisme pour stocker des données structurées dans des tables dédiées en base, pour l'amélioration des performances - le 'custom mapping'. Le prix à payer pour cela est la perte de la possibilité de configurer les structures facilement à partir de l'interface utilisateur. Cette perte n'impacte pas de manière importante l'observatoire car la structure des avis ne change pas très fréquemment (n'a pas changé depuis quelques années) et si ça arrive on peut intervenir au niveau du code pour mettre à jour la structure. Aussi, il y a besoin d'écrire un fichier de configuration des tables.

Pour l'outil JDMA ce mécanisme n'est pas mis en place. Il serait utile pour gagner en performance et améliorer la requetabilité de ces données (il fourni une solution aux particularités de stockage qui bloquent #1110 ). Le travail sur l'archivage (#1189) sera aussi facilité par l'optimisation de la structure de stockage, en performance et en simplicité du code.

Cette tâche est pour préparer la configuration des tables dans la base de données et écrire le fichier de configuration qui va avec.

Note importante : il faudra mettre à jour la documentation d'installation (voir https://github.com/DISIC/observatoire/issues/1191#issuecomment-1333565723)

[raphj]

il faudra mettre à jour la documentation d'installation. Le commit 56d45bfd31dd3e7c43a8e4142f0d87078a5cf9f1 introduit un custom mapping hibernate dans tools-api, il faut indiquer qu'en dessous de toutes les balises similaires dans hibernate.cfg.xml, il faut ajouter :

<mapping resource="observatoire/avis.hbm.xml"/>

[lucaa]

Les configurations des nouvelles tables sont finies et validées. Ce ticket reste ouvert car le travail n'a pas encore mergé sur master, reste sur une branche.

Les autres tâches liées sont nécessaires avant de pouvoir merger sur master, pour garder la cohérence des avis détaillés.

[raphj]

@lucaa @ldubost pour passer les avis existants vers le nouveau système de stockage, il y aura peut-être besoin de mettre une chaine vide dans les propriétés qui ont une valeur nulle, en particulier celles dont le type est Static List.

[lucaa]

@raphj je déplace ce commentaire sur la tâche de migration, car elle concerne la migration.

[lucaa]

Reprise du travail sur cette tâche pour implémenter les éléments suivants:

• ajout d'une propriété supplémentaire dans la classe des avis, la date de l'avis, stockée également dans le custom mapping. Aujourd'hui on utilise la date de la création de la page pour connaître la date d'un avis.
• ajout d'une propriété supplémentaire dans la classe des avis, l'id de l'avis, stockée également dans le custom mapping. Aujourd'hui on utilise le nom de la page de l'avis pour connaître cet id.

L'ajout de ces deux propriétés, presque redondantes, dans la classe des avis et dans le custom mapping, accelerera au maximum les requêtes des avis, car aucun join en base ne sera nécessaire désormais.

Note sur la redondance:

• la date de l'avis ne pose aucun problème de redondance, car elle est une date informative. Le fait qu'elle pourrait se retrouver désynchronisée de la date de création de document n'est pas un problème en soi, l'information qui 'gagne' est l'information de la table des avis. Comme il n'y a pas de mise à jour d'un avis une fois créé, il suffit de mettre en place cette date à la création - voir #1192
• l'id de l'avis est redondant avec le nom de la page, si jamais la page est renommée et l'id n'est pas synchronisé, il se posera la question de l'id qui "gagne". On considère que pour assurer l'unicité dans la base le nom de la page est utilisé et que l'id redondant de la classe d'avis est à utiliser uniquement pour affichage et n'est pas à considérer pour assurer l'unicité. Les avis sont uniquement identifiées de tt manière par l'id de l'objet qui doit être utilisé comme clé unique dans la base, ce nom de la page / avis_id sera utilise uniquement pour pouvoir afficher un ID dans le tableau des avis sur le UI.

[lucaa]

La mise à jour de la définition de la table a été faite, les instructions mises à jour et le code maintenant est dans le master.

Le travail est fini, je ferme cette tâche.

[lucaa]

Le changement de méthode de stockage a été activé en production le 26/12/2022 à 15h00 et 42s.

À partir de cette date tout nouvel avis ajouté est stocké dans le nouveau stockage.