Support for relation entities

[Arachnid]

Sometimes there are entities that should be represented in the graphql schema that don't have corresponding on-disk relations. For instance, we might want to be able to query records related to an address, but don't need to store any information on an address directly:

type Address  {
  id: ID!
  ownedContracts: [Contract!]! @derivedFrom(field: "owner")
  # ...
}

It would be good to be able to represent these in the graph without having to create empty entities for them.

An advanced version of this is an entity that may have a composite key: for instance, representing an individual ERC721 collectible, which entails both a contract address and a token ID.

[Jannis]

This may be hard to generalize for the composite key example.

We have built-in support for Ethereum-native / block explorer style data such as addresses, accounts, contracts planned but there is no timeline for this yet.

[leoyvens]

This is now old and out of context, it would be best to open a new and more detailed issue to discuss this.

[Arachnid]

Without knowing what it is that was confusing, I don't know what detail I can add? I thought the description was fairly clear.

[leoyvens]

@Arachnid I think I understand what you want to achieve, but it is not yet clear to me what new feature or built-in solution would be better than creating a new entity with the derived field. Could you detail the solution you have in mind bit more?

[Arachnid]

The point is that there's no need to create an entity on disk when its only field is the ID. Supposing you have a bunch of records which have an 'owner' field. It'd be good to be able to have an 'Accounts' object in the graph that doesn't require creating a bunch of empty accounts on disk just so that you can query it there.

[leoyvens]

Got it thanks for reinforcing. So you want to write:

contracts {
   # `owner` is of type `Address`
   owner {
      ownedContracts {
        id
      }
   }
}

We could have entities that don't exist in the store as long as all fields are derived. Since there is a way around it, even if inconvenient and inefficient, which is to create concrete entities, I will mark this as low priority.