D’après la doc, c’est bien cela qui se passe en cas de rollback. Comme on pourrait le penser intuitivement, le processor squid va revert les changements en bdd en cas de détection de block orphelin, jusqu’à retrouver un bloc commun, puis ré-indexer à partir de ce bloc.
The processor will periodically (interval setting for EVM, Substrate) poll the RPC endpoint for changes in consensus. When the consensus changes, it will re-run the batch handler with the new consensus data and ask the Database to adjust its state. The Database then must roll back the changes made due to orphaned blocks and apply the new changes. With this, the state of the Database reflects the current blockchain consensus at all times.
Les blocs non finalisé sont flag comme étant hot par squid. Il semble être possible de le configurer pour indexer ou non les blocs “hots”.
Les checkpoints quand à eux, servent en cas d’erreur, de coupure ou de corruption de la base de donnée. Ca permet au processor de reprendre au dernier checkpoint valide en cas de problème, plutôt que de devoir tout réindexer.
PS: quand on tape “subsquid rollback sql” sur google, la première réponse c’est ce forum x)
Manque un peu de ressources côté subsquid…
Ce serait intéressant de tester ces rollback squid pour observer ça concrètement, mais je ne sais pas comment provoquer un fork volontairement sur une chaine de test.
En fait je me suis mal exprimé : je n’ai pas de doute sur les rollback des blocs, mais plutot sur les données indexées à partir des blocs. Transactions ou pas, il faut bien que l’algo parte des bloc, pour retrouver les données liées. Ces données filles doivent donc être liées par une lien physique (foreign key de la base de données) ou un logique (une colonne, sans lien physique : exemple : id d’évenement, id de block, etc.)
Mais effectivement, tester un rollback puis vérifier que tous les index ont bien été nettoyés devrait suffire.
Si je tape juste “subsquid rollback” on arrive en 3ème position avec un message de moi …
bref ça m’est déjà arrivé de rechercher des choses sur substrate et tomber sur ce forum en premier aussi, on reste quand sur des sujets pas si répandu que ça ^^
Oui, pardon, j’ai dû le stopper hier soir car un autre service faisait la gueule sur mon serveur, et j’ai cru que ça venait de la charge CPU. Mais en fait non.
Je viens de le redémarrer.
EDIT: j’avais zappé la question sur la méthode. J’ai juste repris le fichier docker-compose.yml présent dans le dépôt duniter-squid, et j’ai adapté à mon infra.
Dès que Hugo valide ma MR on push une nouvelle image de squid, qui va changer un peu le schéma des identités notamment, donc attendez un peu avant d’adapter vos clients.
add event foreignkey to memberships events to retrives timestamps and events stuff
convert identity username to utf8
add new history.json for gdev 0.8.0
mise à jour de la doc
add Universal Dividends list, UD revals and UD history by Identity
@kimamila cette version doit te permettre d’afficher la liste des DU par identités dans Cesium.
Si c’est galère de merger les historiques de transactions et les historiques de DU par identités, je ferais peut être une requête SQL qui merge les deux, je verrais si c’est pertinent (tu me diras).
C’est la qu’on ce rends compte de l’utilité de Hasura, quand on ne l’a plus ^^
Il aurait permit de faire un computed field pour la requête SQL udHistory sans avoir à gérer manuellement le resolver graphql.
Oui mais on peut le régler par table. J’avoue que je n’ai pas conscience des restructions de la version.
Mais rien que les computed fields pour la requête udHistory ça change tout.
Pas besoin de se taper tout le resolver graphql à la main avec la génération des champs et des clauses.
Ce qui est bien c’est que j’ai fait les deux implémentation donc on peut comparer.
Je vais prendre le temps de faire un poste pour détailler tous les avantages du combo subsquid pour le processor/generation typeORM model TS, et Hasura pour le moteur GraphQL.
Ç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.
Ç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.
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
}
}
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:
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.
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é.