Duniter-squid

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