Requêtes GraphQL à WotWizard

Ben oui, c’est pareil. On n’écrit qu’une fois une partie qui se répète.

2 Likes

https://forum.duniter.org/t/interface-wotwizard/8889/20?u=gerard94

Duniter semble forker sur coinduf.eu. J’ai essayé de réparer, mais ça n’a pas l’air d’avoir marché. Quelqu’un peut jeter un coup d’œil ?

1 Like

@gerard94 pour éclaircir le problème soulevé ici (Plus de 100 certifications?), j’ai cherché à avoir le point de vue de WotWizard. Est-il possible de modifier cette requête pour obtenir le résultat au bloc 262773 ?

{
  idSearch(with: {hint: "PiNguyen"}) {
    ids {
      uid
      hash
      sent_certifications {
        to {
          uid
        }
        block {
          number
        }
        expires_on
      }
    }
  }
}

Pour l’instant, non. Mais les données existent et il suffit de les organiser. Peux-tu reformuler ta demande pour envisager un outil de portée plus générale, comme un nouveau système de types GraphQL ?

On pourrait envisager un nouveau type graphql du type « at(block_number) » dans lequel on pourrait insérer toute requête au format actuel afin d’obtenir son résultat à un bloc défini. Par exemple:

at(block: {number: 262773}) {
    idSearch(with: {hint: "PiNguyen"}) {
        ids {
            uid
            hash
            sent_certifications {
                to {
                    uid
                }
                block {
                    number
                }
                expires_on
            }
        }
    }
}

Ta proposition pose bien le problème, mais me paraît un peu difficile à mettre en œuvre. Je proposerais plutôt que l’argument with de idSearch présente deux nouveaux paramètres facultatifs contenant deux numéros de blocs : after et before. Seules seraient sélectionnées les identités existant quelque part entre ces deux blocs. Ces mêmes paramètres pourraient apparaître dans les appels de Identity.all_certifiersIO et de Identity.all_certifiedIO pour les certifications.
Cela demanderait du travail et du temps. Il faudrait notamment modifier un index important, avec tous les effets de bord possibles qui en résulteraient, et, peut-être, créer de nouveaux index. De plus, le temps de calcul risquerait d’être sensiblement augmenté.
Est-ce que tu penses que ces nouvelles possibilités seront vraiment utilisées ?

1 Like

Non, je pense que ce serait utilisé uniquement par les personnes qui s’intéressent à l’historique de la toile, alors que la plupart des gens et en particulier les utilisateurs de wotwizard sont tournés vers le présent et le futur.

Donc si ça demande trop de travail, ce n’est pas la peine. Je trouverai un autres moyen de comprendre si Pi avait bien 101 certifications sortantes et si oui pourquoi.

1 Like

La réponse ne serait-elle pas là : Plus de 100 certifications? - #10 by tuxmain ?

1 Like

Si, mais j’ai répondu à ce sujet avant d’avoir lu l’autre ^^

Est-il possible de faire une requête à un bloc donné ? Par exemple pour évaluer la distance au moment de l’entrée dans la toile comme suggéré ici : Règle de distance au moment de l'entrée dans la toile

Non, cela n’a pas été prévu et demanderait certainement un bien plus gros espace pour la bdd, ainsi qu’un temps de traitement plus long. À moins de trouver une astuce. As-tu une idée ?

1 Like

Comme je ne connais pas le fonctionnement interne de wotwizard, j’aurais du mal à trouver une astuce. J’ai conçu DataJune pour cet aspect « historique » précisément, mais je comprends bien que si on travaille uniquement avec un index actuel, c’est difficile de répondre à la question. S’il y a moyen de « dérouler » l’historique de la blockchain dans wotwizard, je peux fournir une liste de blocs auxquels évaluer la distance d’une identité. En pseudo code, ça donnerait :

mettre l'index wotwizard au bloc zéro
pour chaque paire (numéro de bloc, identité) dans la liste
    faire avancer wotwizard jusqu'à ce bloc
    calculer la règle de distance pour cette identité
1 Like

Oui, tout à fait. Mais cela suppose une autre architecture de la bdd de WW.

1 Like

J’ai du nouveau par rapport aux problèmes d’introspection qu’on avait dans graphiql. Apparemment Wotwizard utilise une vieille version de GraphQL qui n’était pas reconnue. J’ai testé avec l’extension navigateur https://altairgraphql.dev/, et l’introspection fonctionne bien, tout en disant que c’est une version dépréciée de GraphQL :

2 Likes

J’ai pourtant passé beaucoup de temps à le mettre en accord avec la dernière version publiée de graphQL. C’est bizarre. Je viens de vérifier, la dernière version officielle est celle de 2021, et c’est bien celle que j’ai implémentée.

https://spec.graphql.org/

D’ailleurs les champs DEPRECATED sont vides. Je ne comprends pas bien ce qu’ils font là, le document de définition de l’interface n’a aucune directive @deprecated.
Sinon, bravo pour avoir trouvé un client à jour.

1 Like

Dans ce cas il faudra regarder dans leur code ce qui génère ce message :

image

Mais même comme ça, ça aide beaucoup d’avoir l’introspection !

D’ailleurs Gerard, tant que tu es là, on a des nouveaux devs espagnols qui maîtrisent le Go, est-ce que ça t’intéresserait d’explorer avec l’un deux la piste de la librairie substrate en Go ?

Il me semble qu’ils confondent la version des spécifications officielles du langage (Tags · graphql/graphql-spec · GitHub) et la version de leur implémentation. WotWizard a sa propre implémentation, conforme aux dernières spécifications officielles. En tous cas, il n’y a pas de v0.5.0 dans les spécifications.

Oui, merci. Après beaucoup d’essais infructueux, j’ai abandonné le sujet. La version publiée sur notre GitLab n’en garde pas trace ; j’ai tout effacé et réinitialisé car je m’y étais très mal pris. Je vais essayer de tester la version substrate avec GitHub. Ça évitera les catastrophes sur GitLab.

1 Like

J’ai retrouvé sur matrix (#rust:matrix.hostux.net) :

C’est urko, il faudrait organiser une visio avec lui sur l’utilisation de substrate en Go.

En fait, ce n’est pas trop l’usage de substrate qui me pose problème, mais le fait qu’il faille pour cela gérer les numéros de version des logiciels utilisés. Rust fait déjà cela depuis toujours, mais ce n’est pas le cas de Go, qui s’y est mis depuis assez peu de temps, avec ce qu’il appelle des modules, qui forment un système compliqué, impliquant une référence obligatoire à un serveur publiant ces logiciels (genre GitHub ou GitLab), y compris pour les bibliothèques personnelles. Pas de serveur associé, pas de compilation possible. J’ai essayé avec GitLab, mais je n’arrive toujours pas à compiler. Je bloque complètement. Pour l’instant, je n’utilise pas les modules, qui restent heureusement encore facultatifs. Mais pas de modules, pas de choix de version et pas de substrate.

1 Like