Produits Entr'ouvert » w.c.s.

Est-ce-que ce comportement est connu et voulu, ou s'agit-il d'un bug ?

Il faut regarder dans la table si quelque chose aurait l'air anormal.

Pour donner un contexte :

• dans les workflows il peut y avoir des modèles de documents, qui peuvent être assez lourds,
• historiquement il y avait une règle basique type "si ça fait plus d'1Mo, on n'enregistre pas de snapshot",
• on a fait évoluer pour permettre de plutôt stocker la différence entre deux versions successives, dans l'idée qu'ainsi une modification sur un statut A peut se faire sans avoir à restocker le gros modèle de document du statut B,
• et seulement quand le diff se trouvait plus gros que le workflow en lui-même, enregistrer la totalité, (#57299)

Quelque chose d'anormal ce serait le même workflow enregistré, à répétition, en totalité alors qu'a priori un diff aurait du être enregistré.

wcs_demarches_orleans_test_entrouvert_org=# select pg_size_pretty(sum(coalesce(length(comment), 0))) as comments, pg_size_pretty(sum(coalesce(length(serialization), 0))) as serializations, pg_size_pretty(sum(coalesce(length(patch), 0))) as patchs from snapshots;
 comments | serializations | patchs 
----------+----------------+--------
 1946 kB  | 1539 MB        | 37 GB
(1 ligne)
wcs_demarches_orleans_test_entrouvert_org=# with foo as (select object_type, object_id, sum(coalesce(length(patch), 0)) from snapshots group by 1, 2 order by 3 desc limit 30) select foo.object_type, foo.object_id, pg_size_pretty(sum) from foo;
 object_type | object_id | pg_size_pretty 
-------------+-----------+----------------
 workflow    | 178       | 35 GB
 workflow    | 168       | 735 MB
 workflow    | 162       | 418 MB

Donc oui, y'a un workflow qui a un problème...

wcs_demarches_orleans_test_entrouvert_org=# select extract(week from timestamp), count(*) from snapshots where object_type = 'workflow' and object_id = '178' group by 1 order by 1;
 date_part | count 
-----------+-------
         5 |   792
         6 |   782
         7 |   821
         8 |    84
        13 |   183
        14 |   252
        15 |   241
        16 |   251
(8 lignes)

Plusieurs centaines de changements par semaine.

Plusieurs centaines de changements par semaine.

Mais en soit ça ne devrait pas poser de problème, sauf si c'est à chaque fois "je remplace ce modèle de 20 Mo par un autre nouveau modèle de 20 Mo".

En moyenne 8MB par patch, donc 2GB par semaine, sauf la semaine 6 où on avait 31MB par patch, 25GB sur la semaine.

Si je prends les deux plus récentes modifications, je télécharge, et je diff,

--- snapshot-workflow-21301-20220424-1811.wcs   2022-05-20 09:33:15.837723115 +0200
+++ snapshot-workflow-21302-20220424-1812.wcs   2022-05-20 09:33:09.497675588 +0200
@@ -209977,7 +209977,7 @@
                 <prefill>
                   <locked>False</locked>
                   <type>string</type>
-                  <value>{{mairie_creation_8_var_mairie|default:""}}</value>
+                  <value>{% if form_name == "Demande de livret de famille suite &#224; erreur" %}{{form_var_remise_lf_orleans}}{% else %}{{mairie_creation_8_var_mairie|default:""}}{% endif %}</value>
                 </prefill>
                 <items>
                   <item>Mairie centrale</item>

mais dans la table il y a un diff qui est bien plus volumineux.

(...)

Ce qui est logique le diff est fait par rapport à la dernière version complète.

Tu peux produire pour le workflow 178 la liste des snapshots (order by id desc), avec en timestamp, comment + colonnes la taille des colonnes serialization et patch. ? Pour tenter d'imaginer un meilleur seuil.

8MB

Deux approches pour faire évoluer :

            if len(obj.serialization) > len(patch):
                # serialization is bigger than patch, store patch

j'étais juste avant sur l'idée de faire un len(obj.serialization) / 10 et chercher ce facteur mais peut-être que c'est aussi à combiner avec un truc statique genre len(patch) > 1_000_000.

Étant donné qu'on a encore des personnes avec des instances en PostgreSQL 9.6 (plus supporté pourtant) et que le partitionnement déclaratif a été introduit dans PostgreSQL 10... je suppose qu'il vaut mieux attendre ?

Oui. (mais ça doit se réduire)

Automatic expiration