Sur Simplicité 6.3.15, nous avons identifié deux comportements autour des attributs document. Nous souhaitons savoir s’il s’agit d’anomalies ou du fonctionnement attendu.
1. Sélection de la bibliothèque associée à un attribut document
Contexte :
Objet métier : DemoProduct
Attribut document : demoPrdBrochure
Une bibliothèque B-demoPrdBrochure est créée automatiquement.
Les bibliothèques supplémentaires utilisent le même objet et le même attribut métier.
Scénario observé :
Un document est ajouté dans l’attribut demoPrdBrochure.
Il apparaît dans la bibliothèque initiale.
Nous créons manuellement une deuxième bibliothèque, DemoSecond, associée au même attribut.
Les documents apparaissent alors dans cette nouvelle bibliothèque.
Nous supprimons DemoSecond : le document se retrouve temporairement sans bibliothèque.
Nous créons manuellement une troisième bibliothèque : le document existant y apparaît.
Si nous ajoutons ensuite un nouveau document depuis l’attribut métier, celui-ci apparaît dans la première bibliothèque automatique et non dans la dernière bibliothèque créée.
Questions :
Peut-on officiellement associer plusieurs bibliothèques au même attribut, ou faut-il n’en conserver qu’une seule ?
Si plusieurs bibliothèques sont supportées, comment Simplicité choisit-il celle qui reçoit les nouveaux documents ?
Le comportement observé après la suppression et la recréation d’une bibliothèque est-il normal ou s’agit-il d’une anomalie ?
2. Stockage SQL d’un attribut multi-document
Constat reproductible sur le même attribut demoPrdBrochure :
Avec l’affichage document unique, le doc_id est enregistré dans la colonne prd_brochure.
même si les documents restent accessibles dans m_document.
Est-ce le comportement attendu ou une anomalie ? Pourquoi les identifiants ne sont-ils pas enregistrés sous la forme doc_id1;doc_id2, comme pour une énumération multiple ? Quelle est la méthode pour récupérer les documents associés à un attribut multidoc ?
Je sais que cela fait beaucoup de questions pour un seul post, mais comme les deux sujets concernent directement les attributs document et les bibliothèques associées, je préfère tout centraliser ici
Il ne doit y avoir qu’une bibliothèque par attribut
Un document ne peut être que dans 1 bibliothèque
Le bookshelf est généré, et référence le field en question. Il sert ensuite à indiquer les types de doc supportés (mime type), et les quantités dans le cas d’un champ doc multiple. Il n’y a aucune raison d’en créer une autre ou d’en changer.
Nous n’avons jamais testé d’en avoir plusieurs sur un même champ. Le comportement dans ce cas est imprévisible, il faudra rajouter ce test à l’audit du module pour éviter de faire cette erreur.
La persistance des docs multiples n’a pas de référence croisée dans la colonne du champ qui reste donc vide. La foreign-key ne peut pas être une concaténation de doc IDs, car c’est un champ numérique.
La jointure se fait donc depuis le document (m_document qui référence l’objet, le field et le row_id cible). Par exemple :
List<String[]> docIDs = obj.getGrant().query(
"select row_id from m_document" +
" where dbd_object_id=" + Tool.toSQL(obj.getId()) +
" and dbd_field_id=" + Tool.toSQL(f.getId()) +
" and dbd_row_id=" + Tool.toSQL(rowId) +
" order by created_dt desc");
Mais vous ne devez pas présager de la persistance qui pourra évoluer.
Et donc toujours vous baser sur les APIs des documents qui le feront pour vous :
ObjectField f = obj.getField("myDocField");
if (f.isMultiDocuments()) {
DocumentDB mdoc = f.loadDocuments(obj, obj.getRowId());
if (mdoc != null) {
for (DocumentDB doc : mdoc.getDocuments()) {
String id = doc.getId();
String name = doc.getName();
// doc.getBytes(true), doc.getMIME(), etc.
}
}
}
Dans le cas du multi-docs, DocumentDB est un conteneur de DocumentDB pour que les API retournent toujours un DocumentDB quel que soit le rendering du champ Document mono/multiple.
Merci beaucoup pour ces précisions ! La prochaine fois, je poserai la question avant de tester toutes les configurations possibles à tout-va ^^
Il n’y avait pas de raison fonctionnelle particulière à créer plusieurs bibliothèques sur le même attribut.(voyant que c’était possible, nous avons testé). Ce test s’inscrit dans une étude plus large : nous travaillons sur un objet de gestion permettant de référencer différents stockages documentaires, (internes ou cloud) lié à un attribut d’objet doc. et sa bibliothèque associé ( et non ses).
L’objectif est de permettre aux Designers de choisir simplement leur stockage, puis d’automatiser la gestion des documents, sans exposer toute la complexité technique.
Nous cherchions donc à mieux comprendre le lien entre attribut, bibliothèque et stockage. Votre réponse nous donne une règle claire pour la suite : une seule bibliothèque par attribut et un accès aux documents exclusivement via les API Simplicité.
Merci encore pour votre retour, très utile pour orienter notre conception
