Created
July 1, 2020 19:59
-
-
Save leoyvens/548495adce6f976e5b7f26c484a1acef to your computer and use it in GitHub Desktop.
Grafting instructions
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
## 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: | |
```yaml | |
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