⚠ Relations circulaires compliquées

À l’attention des développeurs d’indexeurs, nous avons un schéma de relations circulaires qui peut être complexe à gérer :

  • une identité est lié à un compte via sa owner_key
  • un compte peut être lié à une identité via son linked_identity

Et on ne peut pas partir du principe que l’un est forcément défini avant l’autre puisque :

  • le compte et l’identité peuvent être créés dans un batch
  • une identité peut être liée à un compte encore non existant (au sens où il n’a pas de monnaie)

Mais je crois que j’en suis venu à bout avec un petit hack dans duniter-squid :

query MyQuery {
  identities(where: {name_eq: "HugoTrentesaux"}) {
    id
    index
    name
    account {
      id
      linkedIdentity {
        name
      }
      identity {
        name
      }
    }
    linkedAccount {
      id
    }
  }
}
{
  "data": {
    "identities": [
      {
        "id": "genesis-344",
        "index": 344,
        "name": "HugoTrentesaux",
        "account": {
          "id": "5Dq8xjvkmbz7q4g2LbZgyExD26VSCutfEc6n4W4AfQeVHZqz",
          "linkedIdentity": {
            "name": "HugoTrentesaux"
          },
          "identity": {
            "name": "HugoTrentesaux"
          }
        },
        "linkedAccount": [
          {
            "id": "5Dq8xjvkmbz7q4g2LbZgyExD26VSCutfEc6n4W4AfQeVHZqz"
          },
          {
            "id": "5DhsQ7PCUNrTqBqiQjxKuQc1GHTn1voQkJYiUtL4H7Lhb3kj"
          }
        ]
      }
    ]
  }
}

On voit que pour une identité donnée, on peut avoir :

  • le compte actuel au sens de paire de clés (la “owner_key”)
  • la liste de comptes liés (au sens des données AccountData)

Et pour un compte donné, on peut avoir :

  • optionnellement l’identité qui l’a actuellement comme owner_key
  • optionnellement l’identité auquel il est lié (au ses des données AccountData)

Voilà, je relis encore un peu puis je publie ça proprement.

3 Likes