Finalement je suis plutôt d’avis de mettre une foreign key sur le bloc ce qui permet de récupérer le timestamp dans une seule requête sans dupliquer l’info dans autant de tables qu’il y a d’événements dans le bloc.
Pareil ici, une foreign key sur l’événement. L’id c’est juste une contrainte technique de squid, c’est pour ça que j’ai mis l’event-id, mais quand c’est un champ, il vaut mieux mettre une foreign key. En plus, à partir de l’event, on peut remonter au call, à l’extrinsic, au bloc :
Oui, on a la même sensation côté Duniter, et @cgeek avait proposé de fusionner tout ça, mais je n’étais pas encore prêt mentalement à franchir le pas (cf Résistance au changement, la nuit porte conseil). Mon idée pour l’instant est que le status est une forme d’index pour éviter d’avoir à filtrer sur un champ lié.
Oui, tout à fait, si on se fie uniquement à l’indexeur, on peut être manipulé par lui. Deux types de mensonges sont possibles : ajout/modification d’information et omission.
Pour l’ajout/modification, c’est pas trop compliqué, il suffit d’aller vérifier dans le bloc ciblé, et si ça ne correspond pas, c’est la blockchain qui a raison (donc c’est soit un bug soit une “attaque” de l’indexeur).
Pour le mensonge par omission, c’est plus compliqué. Si un indexeur ne donne pas une info, la seule manière de s’en apercevoir est de trouver l’info non indexée en blockchain. Cf ce message : Quel indexeur utiliser et scan réseau - #2 by HugoTrentesaux