Produits Entr'ouvert » w.c.s.

L'objet wcs.workflows.ContentSnapshotPart conserve les modifications aux données des fiches et des demandes dans les évolutions.

C'est accompli en recopiant complètement l'ancienne et la nouvelle valeur de formdata.data respectivement dans part.old_data et part.new_data. Ça ne semble pas très efficace car on doit pouvoir reconstruire tout l'historique du formulaire en ne conservant que les données qui ont changées, et uniquement ces nouvelles valeurs (les anciennes peuvent être retrouvées en remontant dans l'historique). À l'époque il a été jugé plus simple de tout conserver pour pouvoir générer les blocs de diff dans l'affichage de l'historique (#62800-14).

Reste que ça semble bien prendre pas mal de place. Pour ne pas parler dans le vent, j'ai lancé un script sur une des grosses instances (ici une grande ville du sud-ouest), pour mesurer l'espace consommé par les ContentSnapshotPart actuellement, et la même mesure (en mesurant len(pickle.dumps(part, protocol=2)) si on retire part.old_data et qu'on retire les clés de part.new_data qui sont identiques dans part.old_data. Cela donne ce script (attaché) et le tableau en fin de description.

TLDR; on passe de 223Go à 20Go, donc l'idée semble prometteuse. Le résultat en production sera un peu moins visible, car la base réelle ne fait que 131Go (bizarre si 223Go de parts...) cela s'explique par la compression que postgresql applique sur les colonnes prenant beaucoup de place (via le mécanisme TOAST), les données sont alors stockées dans une table à part et compressées; reste qu'une division par x10 du volume d'une partie de la colonne même avec une très bonne compression, réduira les volumes échangées entre les instances de w.c.s. et la base (sur le réseau ça n'est pas compressé, là on a vraiment 223Go qui transitent) ainsi que la taille de la base elle même.