À 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.