Quand on fait une mise à jour de duniter squid, il faut tout réindexer de zéro, ou bien on peut conserver les données et ça se débrouille tout seul ?
Ça dépend de ce qu’on fait de notre côté. Jusque là comme on change pas mal de choses on regénère les migrations de la base de zéro, mais à terme si on ne fait plus que des runtime upgrade ou des changement mineurs on pourra fournir les migrations et continuer l’indexation sans repartir de zéro.
Pas besoin de tout réindexer, les migrations Hasura font leur boulo, ça se débrouille tout seul.
1 Like
Ça c’est vrai que si on génère des migrations incrémentales (que ce soir Hasura ou Squid). Et ça n’a d’intérêt de faire des migrations incrémentales que si on prévoit de ne pas ré-indexer. Mais si on ajoute quelque chose (par exemple le DU), il ne sera indexé qu’à partir de la mise à jour, d’où l’intérêt de ré-indexer depuis le début quand on ajoute quelque chose. Tant qu’on est sur un réseau de test récent, c’est assez court de tout ré-indexer (quelques minutes). Quand on aura plusieurs années de blockchain, on évitera de ré-indexer sauf pour les grosses modifications de l’indexeur.
3 Likes
Je viens de regarder sur le nouveau endpoint. Toutes mes requetes Cs² ne passent plus 
snifff car le schema graphql a changé.
par exemple, pour récupérer les certifications, j’avais cette requete :
query CertsConnectionByIssuer($address: String!, $limit: Int!, $orderBy: [CertOrderByInput!]!, $after: String) {
certsConnection(
first: $limit,
after: $after,
orderBy: $orderBy,
where: {issuer: {account: {id_eq: $address}}}
) {
totalCount
pageInfo {
endCursor
hasNextPage
}
edges {
node {
...Cert
identity: receiver {
...LightIdentity
}
}
}
}
}
fragment Cert on Cert {
__typename
id
expireOn
createdOn
creation {
id
blockNumber
}
renewal {
id
blockNumber
}
removal {
id
blockNumber
}
}
fragment LightIdentity on Identity {
__typename
id
name
account {
__typename
id
}
membership {
__typename
id
}
}
Comment faire de même sur le endpoint Hasura ?
1 Like
Oui le schéma graphql a évolué indépendamment de l’intégration de Hasura pour simplifier les champs memberships de identity, et ajouter les historiques d’événements memberships.
Voilà une requête qui réuni certifs émisent et reçus par adresses:
query CertsByAaddress {
identity(where: {account_id: {_eq: "5CQ8T4qpbYJq7uVsxGPQ5q2df7x3Wa4aRY6HUWMBYjfLZhnn"}}) {
certsByIssuerId_aggregate(limit: 10, offset: 0) {
aggregate {
count
}
nodes {
created_on
expire_on
identity {
account_id
name
}
}
}
certs_aggregate(limit: 10, offset: 0) {
aggregate {
count
}
nodes {
created_on
expire_on
identityByIssuerId {
account_id
name
}
}
}
}
}
Comme vue au téléphone, avec pagination par offset malheureusement (issue Hasura API relay).
Mais je vois que la valeur du count vaut la valeur du limit de la page et non de l’ensemble de la liste malheuresement.
Une requête équivalent sans aggregate:
query CertsByAaddress {
identity(where: {account_id: {_eq: "5CQ8T4qpbYJq7uVsxGPQ5q2df7x3Wa4aRY6HUWMBYjfLZhnn"}}) {
certsByIssuerId(limit: 10, offset: 0) {
identity {
account_id
name
}
created_on
expire_on
}
}
erratum
On regarde avec Hugo le schéma Hasura actuel, il reste des soucis, des noms de fields qui ne sont pas bon (enfin qui ne sont pas parlant), qu’on va devoir modifier, et des champs manquant sur les certs.
Donc ne touche pas à cette partie dans Cesium pour le moment, ça va encore bouger, désolé.
2 Likes
Au passage, peut-être est-ce possible d’avoir des noms d’attributs en camelCase, plutôt qu’en snake_case ? 
Edit : a priori on peut changer la convention de nommage : Postgres: Naming Conventions | Hasura GraphQL Docs
Question secondaire : hasura est-il bien un logiciel libre ?
Dans duniter-squid sans hasura, on a choisi le schéma avec soin pour que ce soit compréhensible et facile à utiliser. Pour l’instant avec hasura le schéma est dérivé de manière un peu brute, il nous reste encore à en prendre le contrôle plus finement. Donc pour l’instant mieux vaut rester sur mon instance https://subsquid.gdev.coinduf.eu/graphql qui est à jour sur une version plus stable.
Hasura a comme GitLab une CE et une EE. La CE en version 2 est déjà très puissante et nous facilite la vie, mais je ne sais pas bien ce qu’ils ont prévu pour le futur avec la version 3. Pour camelCase c’est le cas dans squid, on va essayer de coller à ça, je trouve aussi que c’est plus approprié que la snake_case.
PS : voici les langages utilisés dans Hasura, le “λ” du logo vient du Haskell :
1 Like
Et la V3 (dispo en alpha) est écrite en Rust
2 Likes
J’en parlais justement sur mastodon 
Hugo Trentesaux ⏚: "Apparemment #Hasura (v2 en #Haskell) réécrit son …" - Mastodon.zaclys.com (n’hésitez pas à me suivre là bas, j’y suis très actif)
J’ai un peu de mal à suivre vos discussions. Aujourd’hui, si on veut configurer un indexeur fonctionnel est-il nécessaire d’ajouter Hasura ? Car je ne vois rien de tel dans le docker-compose.yml du dépôt duniter-squid.
Merci pour vos lumières
Non, aujourd’hui la doc est à jour (je crois). Mais dans la branche de poka tu peux voir qu’il y a un Dockerfile intégrant Hasura : Dockerfile.Hasura · hasura-graphql · nodes / duniter-squid · GitLab. Et nos discussions sont au sujet du remplacement éventuel du moteur graphql de squid par Hasura. Et “éventuel”, on peut le prendre au sens “possible” ou “prochain”, c’est au choix ><
1 Like
C’est du pur postgresQL. Hasura comprend les computed fields et l’ajoute dans les champs graphQL. Pas besoin d’Hasura pour utiliser des computed fields. Hasura comprend aussi les views et les materialized views.
La version community est sous MIT.
Dans la version libre, il n’y a pas de rate limiter ni de depth limit dans les requêtes gql.
Ç’a peut-être changé. Ça fait un bout de temps que je n’ai plus touché à Hasura…
@poka Tu as regardé les connecteurs ? Il y en a un pour deno : GitHub - hasura/ndc-typescript-deno: Instant Hasura Native Data Connector by writing Typescript Functions. Je ne sais pas si ça peut être utile…
Faut que je regarde ce que tu as fait…
2 Likes
@kimamila je pense qu’on approche d’une version stable du schema graphql.
Voici un exemple pour la requête de certifications que tu demandais:
query CertsByAaddress {
identity(where: {name: {_eq: "poka"}}) {
certIssued(where: {isActive: {_eq: true}}) {
receiver {
name
createdOn
expireOn
createdIn {
block {
timestamp
}
}
}
}
certReceived(where: {isActive: {_eq: true}}, orderBy: {createdOn: DESC}) {
issuer {
name
createdOn
expireOn
createdIn {
block {
timestamp
}
}
}
}
}
}
En fait la seule différence par rapport à avant Hasura, c’est la pagination que se fait désormais par offset malheureusement.
Cette instance est à jour: https://gdev-squid.axiom-team.fr
mdp: my_hasura_password
endpoint: https://gdev-squid.axiom-team.fr/v1/graphql
Dis moi ce que tu en pense, si il manque des choses ?
@ManUtopiK il n’y a en effet pas de rate limier pour le moment, mais au moins, le server GraphQL ne crash pas si on requête trop de ligne, ça va juste mouliner côté client.
Et je vois la possibilité de limiter le nombre de row par table, ce que tu avais d’ailleurs set pour ton indexer:
Désormais, les metadata hasura sont générés à partir du schema.graphql, lui même également utilisé pour générer le model TS via typeORM par subsquid.
Voici le script qui se charge de ça: src/generateHasuraMetadata.ts · 5b7534548a7837ef7b8e0b2bdb365d484afeba11 · nodes / duniter-squid · GitLab
Des commandes sqd simplifient la gestion de tout ça (le readme sur ma branche est à jour, et sqd --help nous montre tout. En gros c’est aussi simple qu’avant à manipuler, mais on a Hasura en plus.
C’est un peu un hybride entre ton indexer et la stack squid
Sauf qu’on ne créer jamais rien via la console admin de Hasura, on génère les metadata à partir du schema.graphql.
# after modifying schema.graphql sqd db:update
Cette commande réuni plusieurs commandes:
sqd codegen
sqd migration:generate
sqd migration:apply
sqd hasura:generate
sqd hasura:apply
Toutes les commandes sont listés dans commands.json
On peut également toujours lancer le moteur graphql de subsquid avec sqd serve si nécessaire, pour comparer l’API graphql par exemple.
Nous n’utilisons plus les migration Hasura, mais uniquement les migrations de squid, ce qui simplifie la stack (Merci @HugoTrentesaux pour ces réflexions et ce peer programming, sans quoi je partais dans une toute autre direction…).
4 Likes
Woah, ça a l’air terrible tout ça !
Pour le rate et depth limit, on peut passer par un proxy qui gère ça, genre GitHub - narrative-bi/traefik-graphql-limits.
1 Like
Cool, je regarde ça dans la journée. Beau travail !!
Salut @ManUtopiK, est-ce que tu seras là au RML18 ? On aimerait travailler sur les clients notamment le jeudi.
Je penses que ton analyse serait bien utile. Et puis ce serait l’occasion de te rencontrer.
Belle journée a vous
3 Likes
Oui, c’est bon je me suis arrangé !
Je viens de remplir le formulaire. Je serai là du Lundi au Vendredi
4 Likes
Extra ! Je vais enfin de serrer la pince
Merci !
3 Likes
Wow, tu as liké en moins de 10s !
Oui, cool, ça va faire du bien de monter en Bretagne un peu !
3 Likes