10 Juin

Ce que j'ai fait le 10 juin

Malgré l'incorporation de la table column_grouping dans ma base de donnée (qu'on avait réussi à importer depuis un fichier csv avec la commande COPY), le TAP ne fonctionnait pas : le problème est résolu, le nom des colonnes était en majuscule dans le xml ce qui ne collait pas avec la bdd puisqu'ils y étaient en minuscules. En a suivi un problème de droit que j'ai résolu, le TAP fonctionne correctement désormais et on pourra trafiquer le .jar plus tard quand François aura obtenu une réponse.

Pour le code python, il ne se lançait pas car je n'avais pas modifié la variable d'environnement PYTHONPATH. Ce problème est réglé, je vais pouvoir correctement étudier le code.

SUITE : J'ai regardé le code plus en profondeur avec Mireille nottament, j'ai noté le fonctionnement global pour me le fixer dans la tête.

Le fonctionnement

On a une sorte de "main" : test_*_mango_annoter.py avec * un nom de usecase (dans l'exemple que j'ai étudié 4xmm_detection)

Dans ce main, on va appeler une méthode de la classe ProductMapper : build_annotations.

Le fonctionnement de build_annotations est assez simple : on va lire le fichier json associé à notre usecase, et on va regarder dans le dictionnaire parameters, plus particulièrement le champ measure.

On fait matcher ce champ avec les noms des mesures usuelles, et on créé l'"appender" associé.

Ensuite, on va venir utiliser la méthode append_measure, qui est un peu le centre du mapping, pour venir écrire dans notre fichier donné par le output_mapping_path. On notera que les appenders utilisent tous le parameter_appender, qui est je pense la grosse fonction qui vient donner toute la cohérence au code (si j'ai compris comment ça marchait).

Je me pose une question : pourquoi ne pas avoir défini les classes des différents appenders comme des classes filles de parameters_appender ?

_Reponses: _ - un certain nombre de fonctions sont communes à tous les appender, cela permet de les factoriser - Cela permet aussi d'utiliser le polymorphisme au niveau de build_annotations: tous les appenders sont des parameters_appender et peuvent etre traités comme tels sans se préoccuper de leur classes réelles.

Il me reste à bien comprendre le fonctionnement de append_parameter, je dois me documenter sur le module etree.