JE ne connais pas toutes les implications. J'imagine qu'il y a une version simple qui serait d'adapter la fonction d'export vers le csv, voir de la remplacer.
Edited
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related.
Learn more.
Activity
Sort or filter
Newest first
Oldest first
Show all activity
Show comments only
Show history only
Mikaël Salsonchanged title from Exporter des clones au format AIRR to Exporter tous les clones au format AIRR
changed title from Exporter des clones au format AIRR to Exporter tous les clones au format AIRR
La demande était de pouvoir exporter tous les clones.
On peut avoir une config spéciale qui fait un --all (ou un --all -r 3 pour ne pas avoir trop de bruit). Ensuite le fichier AIRR est disponible dans les out files du run.
C'est donc facile. La question sur le temps que cela prend. Ne risque-t-on pas de saturer le serveur ? (même s'il y a maintenant cpp-filter-fine).
Si c'est une server-config à part, on peut espérer que non. (On pourrait même dégrader cette config pour qu'elle ne permette pas la visualisation client, hihihi.)
Pour le temps je ne sais pas d'écriture je ne sais pas. Je ferrais quelques essais pour estimer suivant le nombre de clones.
Par contre, je pensais avoir compris qu'il s'agissait d'exporter que quelques clones d'intérêt sélectionnés depuis l'interface. J'ouvre une autre issue spécifique à ce cas.
Comment on fait ça ? Avec une option supplémentaire au C++ pour ne (quasiment) rien sortir dans le .vidjil ?
Par exemple, ou même --no-vidjil-output ? De toute façon, si cela passe par server-fuse il y a un top 100, non ?
Enfin, sans toucher au C++, on pourrait avoir une config finissant par ; cp no-output.vijil ..., mais j'imagine qu'on en peut pas faire cela par !-security ;-)
@magiraud dans #3861 (closed) soulève le problème du .vidjil qui serait trop gros. Une option pour le désactiver serait une solution.
Mais si on a pas de .vidjil, le fuse (voire l'appli web ?) va faire la tête. Quelle stratégie adopter ? Un .vidjil minimal ? Produire le .vidjil mais désactiver fuse ? (cf. « On pourrait même dégrader cette config pour qu'elle ne permette pas la visualisation client »)
Envisageable de le zipper et le dézipper seulement lors de l'usage voulu ? J'ai fait le test sur un fichier .vidjil de 30Mo; on passe ainsi à seulement 1,6 Mo (facteru 20x). Dans ce cas, on pourrait même envisager de charger dans l'interface un fichier zippé. Il y a une librairie pour ça, en open-source que l'on pourrait tester: jszip, et il y en a sûrement d'autres.
Il faudrait en revanche voir comment adapter le serveur la dessus, puisque l'on aurait toujours d'anciennes données en non-zippées.
Au passage, on réduit la bande passante, donc eco-friendly ;-)