GRP-0001 Decorator Hooks, Cron Jobs and Initialisation Handlers

Governance & GIPs Graph Request for Proposal (GRP)
,
6

Thanks for asking :slight_smile:

  • Subgraph developers may wish to hydrate the store with data.

    • One example would be metadata that is not found on-chain, and that is needed in the mapping code.

    • Another example would be storing static data that is needed in the frontend to make their application serverless.

    • A common workaround is to create an onStartup function in the mapping code. You would then identify which handler is triggered first. Inside this handler, you would check if onStartup has been run. (typically by loading and doing a nullcheck on a specific entity from the store). If the entity is null, you would run your onStartup mapping code.

      1. This workaround is not very elegant or intuitive
      2. If a handler runs for too long, it will time out and throw an error. With the workaround described above, a lot of work is done within a single (regular) handler. It is not uncommon to see timeouts when this workaround is used. An initialisation handler could have a higher “gas limit” (See GIP-0005: Gas Costing for handlers)

  • Subgraph developers may wish to index a list of similar contracts that have a common set of triggers.

    • For simplicity sake, let’s take an example where a subgraph developer wants to index 200 ERC-20 tokens. The apparent pattern is to create 200 separate datasources.
    • An initialisation handler allows for a much cleaner pattern: Create a template with the (common) ABI/handlers. Then, inside the initialisation handler, loop through an array with the 200 contract addresses. For each address, they would instantiate a dynamic data source using the template.