Lors de la migration d’une version à l’autre du moteur Simplicité, nous nous sommes rendu compte que des fichiers sont stockés sur notre serveur dans le dossier du template (dans le dossier dbdoc).
Concrètement, notre dossier template-5-3-41 faisait plusieurs centaines de gigaoctets, et quand nous sommes passés en 5.3.71, ce même dossier dbdoc a recommencé a augmenter en taille (à la vitesse en les utilisateurs envoient leurs fichiers dans notre application.
Etant donné que lors d’un changement de version du moteur Simplicité, nous changeons complètement nos liens, plus aucun accès à ces fichiers n’est possibles, et pourtant aucune anomalies est rencontrée dans l’application.
Un template éditeur ne contient jamais de document métier.
Nous n’avons pas connaissance de ce genre d’installation. Ni de comment vous exploitez la solution.
Notre template sert normalement à mettre à jour votre instance /tomcat de dev/test/prod.
Si vous versionnez “tout” à chaque upgrade, il faut penser à copier/migrer le dbdoc dans votre processus dans le nouveau tomcat qui s’excécute.
Mais il convient plutôt de déplacer le dbdoc dans un répertoire partagé (perenne/backupé, externe à vos templates) et paramétrer le param système DOC_DIR vers ce répertoire + vider le cache + redémarrer tomcat.
DOC_DIR vaut BLOB, tout est stocké en BDD et la table m_document est bien alimentée.
Par contre, DOC_LOCAL_DIR vaut dbdoc
Etant donné que depuis des années, la procédure de migration ne mentionnait pas de garder le dossier dbdoc, cela veut dire qu’il est supprimé naturellement lors d’un passage d’un template à un autre, donc pas besoin de le conserver. Le soucis aujourd’hui est plutôt d’identifier le mécanisme qui stocke des fichiers dedans (avec la colonne dbd_content en ). Car notre serveur applicatif se rempli beaucoup.
Dans la doc, DOC_LOCAL_DIR est indiqué comme un “fallback” folder. Ca veut dire que ca stock quelque chose dedans au cas où il y a eu un problème lors de l’envoi? Donc c’est des résidus à purger?
De plus, nous avons un load balancer avec plusieurs noeuds applicatifs répliqués (la base de données elle est unique), donc la présence de ce dossier en local sur chaque machine n’est même pas viable.
Si DOC_DIR=BLOB alors c’est bien la base qui stocke les fichiers.
Le contenu du DOC_LOCAL_DIR sert
de fallback si pas trouvé en base, on prend celui sur le disque en le remettant en base au passage
et à serialiser un fichier si on y accède autrement que par un InputStream, via des appels API du genre obj.getField("myFieldDoc").getDocument(getGrant()).getFile()
Dan ce cas, Simplicité doit écrire le fichier dans DOC_LOCAL_DIR pour retourner sa version java.util.File avec un path physique.
Il faut identifier dans le code applicatif ce genre d’accès, pour n’utiliser que des DocumentDB.getInputStream, ou des copies physiques dans un répertoire temporaire supprimé en fin de traitement.
Vous pouvez voir un exemple de fabrication de ZIP à partir de documents mis dans /temp, sans laisser de trace physique une fois terminé:
