loadRelated is a function that allows users to load derived entities into their handlers. This was previously not possible in the graph-node, but was possible with Matchstick due a bug in the graph-cli that generated getter (and setter) functions for those fields and the way the Matchstick's own entity store works. Derived fields are virtual fields and do not actually exists in the graph-node database. Instead they are created during query time and are only accessible when querying the subgraph. More info on derived fields https://thegraph.com/docs/en/developing/creating-a-subgraph/#reverse-lookups
Matchstick's own store
Matchstick does not work with a database, but implements its own key/value entity store. In the Matchstick store the derive fields actually exists and they keep the IDs of the child entities, hence why the getter/setter functions worked in Matchstick. While this was helpful for users to test their relations, it caused a lot of issues (especially with handling both String and Byte IDs) and made the code complex.
It will probably be wise to refactor the store and make it function similarly to the graph-node, i.e dynamically construct the derived fields when requested. We already keep the derived relations in a separate derived key/value store, but it may not be needed anymore, because the child entity's name, the parent id and the derivedFrom field should come from the loadRelated function itself, which should make it easier to find it in our entity store.
Matchstick implementation:
Graph Node dependency:
We will need to update the graph-node dependencies in order to be able to implement loadRelated
Entity Store:
Looking into the function loadRelated(entity: string, id: string, field: string): Array<Entity>; function we may be able to:
Simplify the matchstick store. - Currently we keep all relations into a separate derived mapping. But the function itself should provide us with the relation info we need in order to fetch the child entities from the entities store, so this mapping becomes obsolete as well as this whole module.
We will no longer need to track the relations into the store directly - the derived_fields module will probably become obsolete
loadRelated
Description:
loadRelatedis a function that allows users to load derived entities into their handlers. This was previously not possible in thegraph-node, but was possible with Matchstick due a bug in the graph-cli that generated getter (and setter) functions for those fields and the way the Matchstick's own entity store works. Derived fields are virtual fields and do not actually exists in thegraph-nodedatabase. Instead they are created during query time and are only accessible when querying the subgraph. More info on derived fields https://thegraph.com/docs/en/developing/creating-a-subgraph/#reverse-lookupsMatchstick's own store
Matchstick does not work with a database, but implements its own key/value entity store. In the Matchstick store the derive fields actually exists and they keep the IDs of the child entities, hence why the getter/setter functions worked in Matchstick. While this was helpful for users to test their relations, it caused a lot of issues (especially with handling both String and Byte IDs) and made the code complex. It will probably be wise to refactor the store and make it function similarly to the graph-node, i.e dynamically construct the derived fields when requested. We already keep the derived relations in a separate derived key/value store, but it may not be needed anymore, because the child entity's name, the parent id and the derivedFrom field should come from the
loadRelatedfunction itself, which should make it easier to find it in our entity store.Matchstick implementation:
Graph Node dependency:
We will need to update the graph-node dependencies in order to be able to implement
loadRelatedEntity Store:
Looking into the
function loadRelated(entity: string, id: string, field: string): Array<Entity>;function we may be able to:derivedmapping. But the function itself should provide us with the relation info we need in order to fetch the child entities from the entities store, so this mapping becomes obsolete as well as this whole module.