Régis WITZ (69a9827b) at 16 Feb 09:24
Régis WITZ (2df98451) at 16 Feb 09:12
Actuellement, l'intégration continue d'Heimdall lance les tests, et en génère un rapport (dans le job test:unit
).
La dernière version de ce rapport de tests se trouve ici : https://datasphere.gitpages.huma-num.fr/heimdall/test/report.xml
C'est un XML basique, assez peu accessible à quelqu'un qui ne parle pas le XML et/ou qui ne sait pas lire un rapport de tests XQuery.
Pour améliorer l'accessibilité des procédure de qualité (ie. tests unitaires) d'Heimdall, ce serait pratique d'avoir un XSL et une feuille de style pour "looker" un peu ce rapport de tests.
@e.falcoz , étant donné que tu nous as déjà fait une très belle documentation, je t'affecte ce ticket.
Il n'a cependant aucun caractère urgent, ou même important.
Done 83fc9bc3
CodeMeta propose entre autres un format de description d'un dépôt de code source, afin que ledit dépôt puisse être "moissonné" et documenté automatiquement, par (entre autres) Software Heritage.
Cette tâche consiste à créer un fichier codemeta.json
le plus descriptif possible.
Régis WITZ (83fc9bc3) at 15 Feb 06:48
Implémentation de la fonction getDatabaseProperties
, requise par la spécification.
La gestion des entités est un vrai sujet auquel j'ai déjà (fait plus que) réfléchi(r). Aussi, je te propose de fermer cette issue pour l'instant.
On en discutera lors d'une seconde séance de rédaction d'un design doc, on ouvrira alors une série relative aux futurs éléments <entity/>
et <property/>
. Et ça amorcera une troisième milestone pour Heimdall.
Ça te va, @gporte ?
Je suis d'accord. Malheureusement, dans le cas d'Heimdall, la manière de proposer une telle fonctionnalité n'est pas trivialle :
xml:hera
peut parfaitement évoluer pour proposer des éléments <entity/>
, <property/>
ou autre. Aucun souci de ce coté là. La question est : comment intégrer ces notions dans les autred formats de bdd ?sql
, cela peut être relativement facile : chaque entité est une table, chaque colonne une property.xml:heurist
ne me semble pas le supporter (quoique ce soit toujours difficile d'affirmer quoi que ce soit en l'éternelle absence de spécification). Les éléments <record/>
ont bien un enfant <type conceptID="xx" />
, mais ces éléments (record)type ne sont décrits nulle part dans le XML.
Heimdall pourrait déduire la composition de chaque (record)type à partir des <record/>
, mais cette déduction serait peu fiable si tu as peu de <records/>
. D'un export à l'autre d'une même base, tu pourrais donc avoir des définitions d'entités différentes. Ça poserait peu de problème si l'application tierce (ie. Estrades) construit dynamiquement ce dont elle a besoin, mais si tu attends une forme d'entité particulière et tout d'un coup hop, ce qui était un base field change de type ou devient répétable, ça risque d'être relou ...csv
, tu n'as pas vraiment de notion d'entité : tu as juste une unique table.rest
... comme d'habitude, c'est spécifique à l'API considérée ...Ces questions se posent surtout lors de l'import (ie. getDatabaseItems
), probablement moins lors de l'export, puisque tout export est fait à partir d'une structure xml:hera
, qui gère les entités. Cependant, certains formats d'export garderont la notion d'identité (sql
), et pour d'autres (csv
, xml:heurist
), cette notion sera perdue lors de la conversion ...
2 formats d'export sont aujourd'hui supportés par Heimdall: csv
et xml:hera
.
"Ça fonctionne" et c'est testé (avec des tests un peu bourrins mais bon...).
C'est aussi documenté (fonction heimdall:serialize
).
Done 54cd60c8