Cantharella-devel

Download

cantharella-devel@list.forge.codelutin.com

April 2014

1 participants
2 discussions

Re: [Cantharella-devel] Stockage des documents
by Adrien Cheype 06 May '14

06 May '14

Bonjour, Éternel débat : stockage des fichiers dans la base ou le système de fichier ? http://wiki.postgresql.org/wiki/BinaryFilesInDB Si vous préférez stocker les fichiers dans la base, je n'y vois pas d'inconvénient. J'ai personnellement toujours enregistré les fichiers à part dans le système de fichier mais dans le contexte de Cantharella, le stockage dans la base suivrait une certaine logique. L'autre question qui se pose alors est : en bytea ou en BLOB (oid) ? Dans notre cas de fichier peu volumineux (cf. limitation de taille définie dans les spécs.), les deux alternatives peuvent convenir. La principale différence étant que pour bytea, les données restent dans une colonne de la table tandis que pour les BLOB, les données sont externalisées dans une table système et référencées par un oid. D'un côté, Bytea semblent être plus facile à mettre en place mais pourrait engendrer certains problèmes de performance lors de requête sur l'ensemble des documents (preload), de l'autre BLOB semble garder toujours de bonnes performances (on demand) même avec des données plus volumineuses mais nécessite de mettre en place un système de suppression automatique des BLOB lorsque la référence (oid) est supprimé (trigger, rule). Adrien Le 14/02/2013 03:23, Eric Chatellier a écrit : > Bonjour, > > Je viens de mettre à jour le serveur avec le début des > interfaces de gestion et visualisation des documents (seulement > pour les molécules avant de le généraliser). > > Concernant le stockage des fichiers attachés, peut-on > les stocker directement dans la base de données ? > > Cela simplifierais la gestion et la cohérence pour l'ajout > et la suppression. > > Techniquement, le modèle de données serait typé en byte[] > voire en InputStream (voire si vraiment ca ne fonctionne pas > en java.sql.Blob) et annoté en @Lob > -- Adrien Cheype Ingénieur en Systèmes d'Information Service « Informatique Scientifique et Appui aux Partenaires du Sud » Direction du Système d'Information (DSI) http://www.ird.fr/dsi/ http://www.ird.fr/informatique-scientifique/ INSTITUT DE RECHERCHE POUR LE DEVELOPPEMENT BP A5 - 98848 Nouméa - Nouvelle Calédonie Tél. +687 260 789

2 2

Tests sur le problème de mémoire actuel
by Eric Chatellier 30 Apr '14

30 Apr '14

Bonjour, J'ai effectué différents test concernant le problème de mémoire qui paralyse Cantharella. Le problème "semble" venir dans page de liste qui: - soit charge trop d'entité (toutes la liste d'un seul coup) - soit ne libére pas les listes chargées (mecanisme wicket de serialisation des pages) - soit quelque chose d'autre n'est pas libéré C'est forcement lié au pièce jointe dans le sens où le contenu des pièces jointe étant dans les entités, le contenu binaire est chargé, même s'il ne sert pas tant qu'on ne visualise ou modifie pas une fiche (specimen, molecules...). Il se produit plus vite avec les pièces jointes, mais ce n'est pas la cause d'origine. J'ai testé: - de détacher les listes dans les modèles de liste : la liste est rechargé à chaque fois, ca rend l'application très lente, mais au final, ca ne résoud pas le problème (peut-être qu'il arrive plus tard, mais c'est pas sûr - de déplacer le contenu binaire dans une nouvelle entité non navigable depuis le document. Cela ne charge jamais le contenu binaire sauf quand on a vraiment besoin. Par contre, cela change trop le fonctionnement pour l'edition/ajout/suppression/modification des documents avec le mecanisme de wicket (usecase). C'est wicket qui sauvegarde le contenu des entités modifiées, et on ne peut pas se permettre de faire des appels service 'autre' que celui de sauvegarde final de l'entité (specimen). - de désactiver le mecanisme de serialisation des page dans wicket (pas pris le temps de pousser vraiment car c'est compliqué). - de mettre à jour wicket (et toutes les autres librairies). C'est fait, mais cela ne corrige pas le problème. Je ne trouve pas de bonnes solutions à la gestion des contenus binaires dans wicket. Et je ne suis même pas certains que le problème soit là non plus: - il est possible que hibernate n'aime pas que l'on charge plein de byte[] d'affilé, et à force, il sature. En surchargeant le setter su contenu binaire pour ne pas le stocker (il est chargé quand même, mais pas stocké dans wicket, et donc non serialisé), le problème se produit quand même. Voilà où j'en suis. -- Éric Chatellier - www.codelutin.com - 02.40.50.29.28

1 0