Skip to content

Instantly share code, notes, and snippets.

@leoyvens

leoyvens/grafting.md

Created July 1, 2020 19:59
Show Gist options
  • Save leoyvens/43f532ec51802b1ce46a7dd90c33371f to your computer and use it in GitHub Desktop.
Save leoyvens/43f532ec51802b1ce46a7dd90c33371f to your computer and use it in GitHub Desktop.
Download ZIP
Raw
grafting.md

Grafting onto Existing Subgraphs

When a subgraph is first deployed, it starts indexing events at the genesis block of the corresponding chain (or at the startBlock defined with each data source) In some circumstances, it is beneficial to reuse the data from an existing subgraph and start indexing at a much later block. This mode of indexing is called Grafting. Grafting is, for example, useful during development to get past simple errors in the mappings quickly, or to temporarily get an existing subgraph working again after it has failed.

A subgraph is grafted onto a base subgraph when the subgraph manifest in subgraph.yaml contains a graft block at the toplevel:

description: ...
graft:
  base: Qm...      # Subgraph ID of base subgraph
  block: 7345624   # Block number

When a subgraph whose manifest contains a graft block is deployed, Graph Node will copy the data of the base subgraph up to and including the given block and then continue indexing the new subgraph from that block on. The base subgraph must exist on the target Graph Node instance and must have indexed up to at least the given block. Because of this restriction, grafting should only be used during development or during an emergency to speed up producing an equivalent non-grafted subgraph.

Because grafting copies rather than indexes base data it is much quicker in getting the subgraph to the desired block than indexing from scratch, though the initial data copy can still take several hours for very large subgraphs. While the grafted subgraph is being initialized, the Graph Node will log information about the entity types that have already been copied.

The grafted subgraph can use a GraphQL schema that is not identical to the one of the base subgraph, but merely compatible with it. It has to be a valid subgraph schema in its own right but may deviate from the base subgraph's schema in the following ways:

  • It adds or removes entity types
  • It removes attributes from entity types
  • It adds nullable attributes to entity types
  • It turns non-nullable attributes into nullable attributes
  • It adds values to enums
  • It adds or removes interfaces
  • It changes for which entity types an interface is implemented
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment