A vrai dire, je ne maîtrise pas BMA et ne sait pas bien à quoi corresponds :search en dehors d’une pubkey, c’est un script selon Duniter c’est ça ?
De mon côté je ne connais aucun service utilisant autre chose qu’une pubkey à cet endroit (dans ce que j’ai implémenté comme g1-stats par exemple).
Il faudrait confirmation de @Paidge pour wotwizard-ui mais je pense qu’il ne se base que sur le serveur wot-wizard, qui lui se base uniquement sur les bases de données de Duniter directement et des fichiers tampon.
Ca me semble une bonne idée, ça permet de ne pas casser la compatibilité avec les versions de Cesium et Duniter tout en gardant la possibilité des recherches avancés.
Mais mon humble avis perso est de ne pas t’embêter avec ces recherches avancés qui ne semblent pas implémentés nul part (attendre confirmation de Paidge tout de même), et de simplifié l’API à ce niveau si cela permet des gains en efficacité.
C’est soit une pubkey, soit un uid (ou une partie de).
Ce qui est étrange, c’est que l’implémentation depuis LevelDB n’est plus la même que quand Duniter utilisait SqlLite. LevelDB fait l’équivalent d’un like; sous SQLLite c’était un uid = ? or pubkey = ?
Bref.
Après vérification du script de @tuxmain pour la wotmap, il va chercher directement dans "~/.config/duniter/duniter_default/data/leveldb".
Pour wotwizard-ui, c’est effectivement un serveur Wotwizard qui est interrogé. Donc, pas d’impact de ce côté- là
Même si je ne m’y connais pas tellement côté Duniter, je pense que pouvoir requêter directement sur une clé permettrait sûrement de gagner en temps de réponse (ça me paraît logique en tous cas).
Perso j’ai jamais utilisé d’API Duniter, sauf dans Datajune où je récupérais uniquement les blocs avec /blockchain/block/000. Par contre sur la v2, je devrais pouvoir répondre à toutes les questions ><.
Merci @Pini !!
Je viens de tester : on est passé de 30s à 3s sur ton instance donc gain x10
Sur g1.duniter.org, ont devrait passer à 200ms, ce qui me semble déjà plus acceptable.
$ npm run format:check
> duniter@1.9.0-dev format:check /builds/nodes/typescript/duniter
> prettier --list-different 'app/**/*.{ts,json}'
app/lib/dal/indexDAL/leveldb/LevelDBIindex.ts
app/lib/dal/indexDAL/sqlite/SqliteIIndex.ts
app/lib/dal/sqliteDAL/IdentityDAL.ts
app/modules/bma/lib/controllers/wot.ts
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! duniter@1.9.0-dev format:check: `prettier --list-different 'app/**/*.{ts,json}'`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the duniter@1.9.0-dev format:check script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR! A complete log of this run can be found in:
npm ERR! /home/user/.npm/_logs/2023-05-16T14_33_27_147Z-debug.log
Cleaning up project directory and file based variables 00:01
ERROR: Job failed: exit code 1
oui, c’est moi qui est fait une erreur, en voulant simplifier l’usage du nouveau paramètre ?pubkey. Je voulais éviter de devoir écrire ?pubkey=true, mais du coup j’ai introduit une erreur.
C’est maintenant corrigé. @cgeek je n’ai pas ajouté grande chose de nouveau, sauf une méthode dans ParamerService pour parser ?pubkey (en gérant la valeur par défaut). Bref, les tests passent, dont j’ai mergé.
C’est plutôt avec @cgeek qu’il faut voir ça, non ?
D’ailleurs, je crois avoir vu dans le code de la branche “dev” que certaines requêtes BMA sont déléguées au module duniter-gva.
Du coup, je me demande comment cela fonctionne en Duniter 1.8 ? Pour les autres architectures je veux dire.
Je te fais une réponse publique ici : je te laisse décider ou non de merger, et de manière générale de mener les correctifs et évolutions sur Duniter v1.
Je n’ai tout simplement pas le temps et l’énergie de mener ce sujet Duniter v1 en plus de mes activités actuelles. Faites sans moi, éventuellement j’interviendrai si l’occasion se présente.
En plus il y a quand même pas mal de tests automatisés, et puis @Pini et @tuxmain suivent un peu l’affaire.
Au pire en cas de gros problème, rollbackez sur une ancienne version de Duniter.
