# The Graph

The Graph allows you to index the events for a given contract. You can do it very easily, creating the schema, the handler functions, and mapping the events for a given contract address and ABI to the handler functions.
But, what happen when the contract that you want to index is created within a contract function (like a factory)?

# Template Feature

In this case, The Graph has the concept of "template". When the "factory" contract emits the event (lets say "NewContractCreated"), in the handler, you can tell to TheGraph, start to index this new address using these handlers and ABI.

# Issue

This "template" feature is very useful and needed because a lot of contract uses this "factory" approach. The issue is when you don't use a contract function to "create" the "child" contract, and instead you pass the "child" address directly to a "register/add" function. This last approach opens the door to loss data from not-indexed transactions.

# Example

(#Block - Action)

#1 - Factory contract is deployed.
#5 - Child A is deployed
#6 to #10 - Transactions to Child A sent.
#15 - Child A is added/registered into the Factory contract.

In this flow, all the transactions between #5 and #10 are lost, because using the "template" feature, The Graph doesn't know (and cannot know dynamically) that the Child A was deployed at #5.
The Graph knows that the Child A was "registered/added" into the Factory in #15, and so then start to index all the event from it.

The issue may be more complex, if for example, the Child A contract creates another SubChild 1 contract.

# Fix (?)

So, how to fix it? and how easy or hard is to fix it?

It depends, but it is not easy because The Graph allows you to define entities and save items into them. So, the code should validate if the contract already exists in all the handlers, if not, create it (sometime at that point, you don't have all the required values to create it).

The only way (at least I know till now) to try to fix it is creating a hardcoded handlers for the given Child A address and ABI.

# How to avoid this issue?

We would need to deploy the contracts in order. It means:

1. Deploy the registry.
2. Deploy a new vault and NOT send txs to the vault.
3. Add the deployed vault into the registry.
4. Start sending txs to the already added vault.
5. Strategy
I. Option 1
a. Deploy or clone a new strategy.
b. Add the deployed strategy into the vault.
II. Option 2
a. Deploy or clone a new strategy.
b. Add the deployed strategy into the vault.
c. Migrate the strategy to the new one.
6. Start sending txs to the already migrated or added strategy.