Purger proprement m_document / Avoir un outil d'audit de liens morts

Request description

Bonjour,

J’aurais voulu savoir quelle est la manière la plus propre pour purger proprement la table m_document ?

L’Action eraseDeadDoc répond elle à ce besoin ?

Merci d’avance,

Benoit

Technical information

Instance /health
[Platform]
Status=OK
Version=5.3.11
BuiltOn=2023-08-07 15:27
Git=5.3/015368bc51913a479e8d682d65ea405c12b45951
Encoding=UTF-8
EndpointIP=xxx
EndpointURL=xxx
TimeZone=Europe/Paris
SystemDate=2023-09-26 10:12:36

Bonjour,

Avant tout il faudrait vous mettre à jour sur la révision 5.3 à jour (5.3.15), depuis la révision 5.3.11 que vous utilisez il y a eu ~160 commits.

Ensuite, quel est votre besoin de “purge” de la table m_document ?

Cette table contient des documents attachés à des records d’objet métier, quand un tel record est physiquement supprimé, les records documentaires associés sont aussi supprimés. Donc, nominalement, la table m_document contient uniquement des données “vivantes”.

Cela dit, il peut y avoir des cas d’erreur compliqués qui aboutissent à des documents “morts” = plus rattachés à un record d’objet métier, c’est pour cela qu’il existe cette action de maintenance chargée de supprimer ces documents “morts”.

Avant de s’en servir, mon conseil est de faire une analyse/recherche préalable de ces documents “morts” afin d’avoir une idée du volume dont on parle. Dans le passé, des anomalies sur cette action ont eu des conséquences parfois néfastes (suppression injustifiée de de documents). Je suis donc (cet avis n’engage que moi) très (trop) prudent lorsque j’envisage de l’utiliser…

Bonjour @david,

Pour le passage à la version 5.3.15, c’est en cours, nous avons certains tests actuellement, suite à certaines régressions/modifications ayant entrainé des problèmes suite au passage en 5.3.13.

Le besoin est en effet de purger des documents “morts” n’étant plus rattachés à aucun record d’objet métier.

Existe-t-il une façon simple pour récupérer ces documents “morts”, ou faut il passer par une requête SQL “custom” ?

Il n’y a pas de requete SQL simple car la table m_document référence des objets via leurs IDs, des attributs des objets via leurs IDs et des records de cet objet via les row IDs.

Sous contrôle de @Francois, il faut donc d’abord obtenir la liste des tables/colonnes, ex:

select distinct d.dbd_object_id, o.obj_dbtable, d.dbd_field_id, f.fld_dbname
from m_document d, m_object o, m_field f
where d.dbd_object_id = o.row_id 
and d.dbd_field_id = f.row_id
and o.obj_name like 'Demo%'

Puis regarder table par table s’il existe des records morts, ex:

select d.row_id, d.dbd_name from m_document d
where d.dbd_object_id = 2029
and d.dbd_field_id = 8604
and not exists (select 1 from demo_product x where d.dbd_row_id = x.row_id);

Bonjour,

Il y a une multitude d’usages possibles des documents, et la plateforme ne connait pas tous les usages “custom”. Nous avons eu des mauvaises surprises dans des cas non-repoductibles.

EraseDeadDoc élimine donc les références mortes mais pas toutes, certaines ont été mises en quarantaine faute de trouver de solution fiable.

Dire qu’un document est mort est semi-décidable dans un cas général. Par exemple en cas d’héritage complexe, on ne sait pas dire si l’objet du document existe encore au niveau du parent et/ou des héritiers pas forcement vers la même table.

Un document mort peut-être :

  • une référence morte dans la colonne de la table métier, le row_id du document n’existe plus dans la table m_document (cas d’un champ doc simple, attention dans le cas d’un champ multi-doc la colonne reste null)
  • une référence morte dans l’autre sens, une ligne dans m_document pointe sur un row_id qui n’existe plus dans la table métier
  • le document physique (si on n’est pas en BLOB) n’existe plus
  • le path dans m_document n’existe pas/plus physiquement

EraseDeadDoc réalise un scan de ces approches, et purge/corrige les cas simples.
Les 2 premières peuvent se faire via des outer join simples avec vos tables métier.

Attention de ne pas supprimer autre chose que vos documents et faire une sauvegarde ou un test préalable sur une copie de la base + docs.

Je note qu’on pourrait avoir pour cette action un mode “audit/scan” uniquement pour controle et/ou suppression manuelle d’une liste d’incohérences.

1 Like

Bonjour @Francois

Oui, cela serait top, la table m_document est de loin la plus sensible, avoir certains outils d’aide/de gestion serait bien venu, le besoin revient souvent, spécifiquement pour la purge des liens “morts”.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.