Table inheritance

[mihoward21]

Can't find anything about this in the docs. Wonder if ponder supports table inheritance? Or there's some other way to accomplish that?

Basically right now in TheGraph I have an Account interface with just a few fields, then a bunch of entities that inherit that interface (each with their own unique fields). Is there any way to do something like that? The reason being I will need to do some queries on Account that will include all the different entities. There are also some relationships between the entities (i.e. the Split entity has a controller field that can be any Account).

Right now doing a separate table for each entity doesn't work (I think), because of that relationship issue (controller could be any Account). But doing a single Account table will get super messy because there will be a ton of optional fields for each different entity.

[0xOlias]

Hi, welcome and thanks for opening @mihoward21 !

Will get back to you with a longer response shortly. In the meantime, can you share an example of a query that you run against your subgraph that uses an inherited/"interface" entity?

[mihoward21]

Here's our current subgraph: https://thegraph.com/hosted-service/subgraph/0xsplits/splits-subgraph-ethereum

Here's two sample queries that highlight what I'm talking about:

{
  accounts(first:5 orderBy:latestBlock orderDirection:desc){
    __typename
    id
  }
  swappers(first:5){
    __typename
    id
    beneficiary{
      __typename
      id
    }
  }
}

The first just fetches accounts ordered by latest block they were updated. This is a simplified version of a query we run in our app to give users a live view of recent activity. As I mentioned, Account is an interface here, with several different entities inheriting from it.
The second query fetches the beneficiary field on a Swapper, and a beneficiary can be any Account.

You can see our schema here if it helps: https://github.com/0xSplits/splits-subgraph/blob/master/schema.template.graphql

[0xOlias]

Thanks, that's helpful.

Background

This isn't a direct answer, but some background might help explain why this isn't an easy decision. In a subgraph, the schema.graphql file defines both the GraphQL schema (public API) and implicitly the database schema (private, opaque API). In my opinion, this coupling was a mistake, and it's one of the problem areas that we’ll solve with Ponder.

Ponder's ponder.schema.ts file works the same way today, but soon we're going to make the Ponder database part of the public API, and "demote" the GraphQL API to be one of many ways to access indexed data, not the only way. When this happens, ponder.schema.ts will only define the database schema - the GraphQL schema will be downstream, and will probably have its own configuration (eg add your own custom resolvers, etc).

Database table inheritance

In database design, I'd consider table inheritance a relatively niche feature.

• Postgres supports it, but caveats it heavily.
• Prisma doesn't support it.
• I've worked on a large Rails codebase that spent years untangling model/table inheritance patterns.

Considering how young Ponder's database schema definition API is, I doubt we’ll support this any time soon. It’s also worth mentioning that the Graph does not use table inheritance to implement interfaces.

GraphQL entity inheritance

With all that said, I think inheritance (via interfaces) at the GraphQL layer is handy, and I can see that you are using it to great effect in your subgraph. I think there will be a clearer path forward here once we ship direct database access and fully decouple the GraphQL API from the database API.

Will add that we're very excited to unblock y'all at 0xSplits, and posts like this genuinely help us prioritize. Thanks for your patience.

[mihoward21]

Thanks for all that background, that's super helpful. Definitely makes sense what you are saying, supporting it at the GraphQL layer. I think if we were starting from scratch we could certainly design without this.

Have really enjoyed digging into Ponder. Not sure we're ready to switch over to it just yet, but have enjoyed playing around with it and am excited to (hopefully) use it in the future.