Prototype de GVA

Aaaaaaaaaah je savais bien que y’avais moyen de faire comme ça ahaha

Je ne sais pas du tout comment ça ce passe avec Rust, mais avec apollo server en nodejs, tu peux créer des loaders pour éviter de requêter plusieurs fois la même donnée :

https://www.apollographql.com/docs/apollo-server/data/data-sources/#what-about-dataloader

On a l’equivalent, la lib rust async_graphql à son propre système de cache. Et pas dessus ça on a en plus le cache de la db sled.

tu verras que si te refait deux fois la même requête c’est plus rapide là 2ᵉ fois :slight_smile:

3 Likes

Petit question relative à des bugs qu’on me soumet souvent sur Cesium (exemple : ticket #931) : est-ce possible via GVA de faire des recherches insensible à la casse ? (sur les UID)

Pour le moment il n’est pas encore possible de faire des recherches par UserID. Mais quand ce sera implémenté oui bien sûr que ça pourra être insensible à la casse, je n’y vois pas d’
inconvénient :slight_smile:

En revanche, je souhaiterais pouvoir rapidement supprimer les UserID (probablement dès DUBPv14), car ils ne servent à rien et font doublons inutiles avec les noms de profil Cesium+.

2 Likes

3 messages ont été scindés en un nouveau sujet : Supprimer les UserID?

@tuxmain a implémenté la requête permettant d’obtenir les fiches de peer et les HEADs, j’aurais préféré qu’un autre contributeur y arrive, mais @HugoTrentesaux et @vit n’ont malheureusement pas poursuivi l’exercice après l’atelier :upside_down_face:

5 Likes

C’est possible dans l’API de graphql de wotwizard

Bravo @tuxmain , gestion des fork au démarrage de Gecko imminente.

2 Likes

Pendant le hackathon, @1000i100 à passé une journée en peer programming avec moi pour implémenter la requête GVA « endpoints », cette requête vous retourne tout les endpoints connus pour l’API demandée :

5 Likes

Et du coup, je vois que tu as fait le changement pour mettre endpoints dans network.
aurais-tu le commit de ce changement que je vois comment tu as fait ?

Merci !

network_db.peers_old().iter(.., |it| {
Je vois à plusieurs endroits peers_old. Pourquoi old ?

Pour différencier de la future collection peers qui stockera le nouveau format de fiches de peer, notamment sans les peer partagés et sans les champs obsolètes.

1 Like

Ca s’annonce bien tout ca ! :slight_smile:

2 Likes

Ajout du champ receivedTime pour les transactions en mempool: il s’agit de la date et heure de première réception du document transaction par le nœud Duniter.

À la demande de @kimamila, cette information à également été ajoutée dans BMA, dans le champ time, ce champ valait null pour les transactions en attente, il contiendra désormais la date de réception du document :slight_smile:

À noter que le champ time contenait déjà la date d’écriture en blockchain pour les transactions écrites en blockchain.

Il semblerait que le code de Cesium n’est même pas besoin d’être modifié, car la date et heure de la transaction est le résultat de l’expression time || blockstampTime

Quant à GVA, il y a déjà depuis plusieurs mois le champ writtenTime pour les transactions en blockchain :wink:

Aujourd’hui j’ai réalisé quelques tests de ce nouveau champ receivedTime et il semble fonctionner. J’ai également testé la bonne valorisation du champ time dans BMA pour les transactions en attentes, là aussi ça semble bien fonctionner :smiley:

6 Likes

Énorme !
Ça veut dire qu’on va pouvoir s’appuyer sur des blocs plus ancien pour émettre les TX, et limiter au maximum les risques de pertes de TX a cause de fork. :slight_smile:

La prochaine version de Cesium va être sympa (commentaires chiffrés, scan réseau en tâche de fond, TX lié au bloc HEAD - 100) !
Faut juste que je trouve du temps pour la finir :slight_smile: mais notre bébé va mieux (après des soucis les premiers mois). Je vais pouvoir sortir la tête de l’eau.

5 Likes

Je suppose que c’est une typo : written time

1 Like

Une requête importante pour plein d’outils est les certifications (liste des certifications d’une identité et toutes les certifications).

@elois penses-tu que je peux m’en occuper ? Il me semble que tous les ingrédients sont là. :man_cook:

Je pense ajouter des champs issued et received à GvaIdtyDbV1. (ou issued_certs ou certs_issued, j’hésite toujours entre l’avantage du préfixage et le respect de la grammaire anglaise)

1 Like

Oui tu as les compétences pour. Par contre il faut qu’on prenne bien le temps de réfléchir à quel schéma de DB, et pour cela il faut partir du besoin. Je te propose de commencer par écrire les requêtes graphql que le client doit pouvoir faire, en précisant bien quelles données il doit pouvoir obtenir.

C’est seulement à partir d’une description non-ambigue du besoin qu’on pourra réfléchir à un schéma de DB optimisé pour ce besoin :slight_smile:

1 Like