trop tard j’ai mergé mais on peut faire une branche hasura-latest oui.
1 Like
Ok, et pour les images dans le container registry maintenant ça s’appelle “server” ?
Dans le docker compose, tu es repassé sur dockerhub :
duniter/squid-app-gtest:v0.4.11
1 Like
Oui en effet je me suis souvenu de ce registry seulement après, il faudrait clarifier si on utiliser encore ce docker hub ou non et si non tout archiver dessus.
Et je se sais pas comment on pousse sur ce registry gitlab, à voir.
C’était pas la CI qui poussait sur le registry justement ?
Ah bah oui je découvre le travail de @Moul à ce sujet !
Je n’ai pas du tout lancé le CI pour squid, mais pourtant j’ai poussé des tags de version ça aurait builds au vue des rules.
Je viens de push un tag et ça a bien lancé des jobs de build en success, mais rien de push sur le registry.
Oulalala je vais trop vite, si ça a bien publié sur le registry à l’instant tout va bien, il faut juste rajouter le job pour l’image PostGraphile.
2 Likes
J’ai un soucis pour l’instant avec le docker compose :
manifest for duniter/squid-graphile-gtest:v0.4.11 not found: manifest unknown: manifest unknown
Alors que je le vois bien là : https://hub.docker.com/r/duniter/squid-graphile-gtest/tags
v0.4.11
→
0.4.11
v
1 Like
Normalement le docker compose fournit fonctionne clé en main, modulo le .env à reprendre de l’exemple ainsi que le network avec noeud duniter à check en fonction de sa config.
Skill issue, je sais pas faire du copier coller 
processor:
image: duniter/squid-app-gtest:v0.4.11
db:
image: duniter/squid-postgres-gtest:0.4.11
server:
image: duniter/squid-graphile-gtest:v0.4.11
Et j’avais mis le “v” partout alors qu’il n’est pas sur l’image db.
1 Like
Non, en fait c’est le docker-compose.yml qui est faux, il ne devrait y avoir de “v” nulle part.
Si c’est bien ça, il faut juste merger !32
2 Likes
Je viens d’installer le nouveau SQUID, qui semble fonctionner (quand je fais la commande):
graphql-client introspect-schema https://squid.gtest.fr.brussels.ovh/v1/graphql | jq
Par contre, est-ce qu’il y a toujours un accès admin comme avec Hasura ?
Je ne vois pas de configuration pour cela dans la partie “server”…
Pour info, avec Hasura, on avait la config:
HASURA_GRAPHQL_ADMIN_SECRET: ${HASURA_GRAPHQL_ADMIN_SECRET}
Et l’accès via url du genre:
https://squid.gtest.fr.brussels.ovh/console/api/api-explorer
Non nous n’avons plus d’accès admin.
Mais nous avons un graphqil publique: https://squid.gtest.fr.brussels.ovh/graphiql
Après rien n’empêche aux admin d’installer phpPgAdmin ou tout autre interface d’admin pour postgres.
On peut aussi notre propre admin duniter squid à terme, free (comme avait commencé à le faire @ManUtopiK sur sont indexer maison initial d’ailleurs)
2 Likes
Tu peux aussi utiliser le graphiql cloud d’hasura :
Mais il y a déjà un graphiql embarqué avec le noeud graphile comme je l’ai dit.
3 Likes
Je suis en train de regarder d’un peu plus près le schéma graphql généré par postgraphile et il y a des trucs que je trouve moches et d’autres dont je ne comprends même pas la provenance.
Par ex certIssued spécifié dans le schéma graphql a été remplacé par le générique et moche certsByIssuerId, transfersIssued par transfersByFromId (??). Et commentsIssued a été remplacé par authoredTxComments. D’où vient “authored” ? Ça ne figure nulle part dans le code, c’est donc graphile qui l’a inventé ?
(je suis en train de reprendre le boulot de Joss dans Duniter panel et squid version postgraphile).
1 Like
Je crois que ce format de nom est généré par le plugin PgSimplifyInflectorPlugin, qu’on peut simplement désactiver dans la config.
Je viens de tester de lancer squid sans ce plugin graphql pour Graphile, ça donne bien des noms différents mais ce n’est pas encore ce qu’on voudrait je pense:
allAccounts
allBlocks
allCalls
allCerts
allCertEvents
allChangeOwnerKeys
allEvents
allExtrinsics
allIdentities
allItemsCounters
allMembershipEvents
allMigrations
allPopulationHistories
allSmiths
allSmithCerts
allSmithEvents
allTransfers
allTxComments
allUdHistories
allUdReevals
allUniversalDividends
allValidators
accountById
blockById
callById
certById
certEventById
changeOwnerKeyById
eventById
extrinsicById
identityById
identityByAccountId
itemsCounterById
membershipEventById
migrationById
populationHistoryById
smithById
smithByIdentityId
smithCertById
smithEventById
transferById
txCommentById
udHistoryById
udReevalById
universalDividendById
validatorById
account
block
call
cert
certEvent
changeOwnerKey
event
extrinsic
identity
itemsCounter
membershipEvent
migration
populationHistory
smith
smithCert
smithEvent
transfer
txComment
udHistory
udReeval
universalDividend
validator
squidStatus
version
Les noms que tu cites proviennent des @derivedFrom du schema graphql qui est un tag spécifique à subsquid, fait pour mapper avec le model typescript.
Graphile ne connait pas ce tag et ne le traite pas.
1 Like
Autre truc qui va être assez relou. J’avais une requête pour chercher une certification :
# certification detail
query CertDetails($issuer: String!, $receiver: String!) {
cert(
where: { issuer: { name: { _eq: $issuer } }, _and: { receiver: { name: { _eq: $receiver } } } }
) {
id
isActive
createdOn
updatedOn
expireOn
certHistory {
blockNumber
eventType
}
issuer {
index
status
}
receiver {
index
status
}
}
}
Je vois pas comment reproduire ça. condition c’est trop simple, et filter permet pas d’aller chercher un champ d’une table liée. (j’ai lu https://www.graphile.org/postgraphile/filtering/#filter-plugin, je comprends les enjeux de performance, mais là c’est assez gênant, ça me fait regretter les autres moteurs)
Pas vraiment, c’est la base du schéma :
"Identity"
type Identity @entity {
"Identity index"
index: Int! @index @unique
...
"Certifications issued"
certIssued: [Cert!] @derivedFrom(field: "issuer")
Actuellement je serais d’avis d’autoriser les filtres complexes pour avoir le maximum de liberté et simplicité dans le développement des clients. Et dans un deuxième temps si on voit que les serveurs sont trop souvent sous le feu d’attaques ou mangent trop de ressources, on whitelistera les requêtes complexes “légitimes”.
C’est le boulot de la blockchain de mettre des quotas d’utilisation. Comme on est dans un système distribué, on peut juste répliquer au besoin les indexeurs. Si quelqu’un les attaque tous en même temps c’est chiant, mais en attendant ça fait beaucoup de boulot que je qualifierais d’“optimisation précoce”.
1 Like
Un problème à la fois (je n’ai pas creusé les options du plugin de filtres avancés de Graphile, tu en sais peut être plus que moi) 
J’ai créé une branche où j’ai créé un plugin Graphile qui prends en compte notre schema.graphql, avec le field @derivedFrom.
Le plugin ts ne fait que 120 lignes, 2 fonctions, vraiment très simples.
Avec ça, j’arrive bien à reproduire exactement les noms que tu souhaites je pense.
Je te laisse tester en local voir si c’est ce qui te convient.
3 Likes
Autre changement que je remarque. Les champs montant (amount) sont des chaînes de caractères (str) avec PostGraphile au lieu d’entiers (int) pour Hasura.
1 Like
En fait ils sont de type BigFloat, car postgres stock les bigint du schema graphql en type numeric, interprétés en bigfloat par graphile.
Peux-tu me dire comment détermines-tu que c’est un type string ?
Il me semble que javascript interprète les trop long BigFloat en string.
J’ai fait un plugin pour garder le type bigint côté graphql au lieu de bigfloat.
