From 0758450549af57701423091d3eee56b0dfb66c93 Mon Sep 17 00:00:00 2001 From: Dmitry Zakharov Date: Wed, 5 Mar 2025 17:03:29 +0400 Subject: [PATCH 1/2] Clean up outdated parts and add more examples --- docs/HyperIndex/Advanced/reorgs-support.md | 9 -- docs/HyperIndex/Guides/configuration-file.mdx | 7 +- docs/HyperIndex/Guides/event-handlers.mdx | 88 +++++++++++++++++-- .../supported-networks/any-evm-with-rpc.md | 4 +- docs/HyperIndex/supported-networks/index.md | 4 +- 5 files changed, 88 insertions(+), 24 deletions(-) diff --git a/docs/HyperIndex/Advanced/reorgs-support.md b/docs/HyperIndex/Advanced/reorgs-support.md index d3dca627..31f789d6 100644 --- a/docs/HyperIndex/Advanced/reorgs-support.md +++ b/docs/HyperIndex/Advanced/reorgs-support.md @@ -5,10 +5,6 @@ sidebar_label: Reorgs Support slug: /reorgs-support --- -:::note -This feature, while functional and stable, is not optimized. If you choose to have this feature enabled, please be aware that historical indexing may slow down. We want to ensure blazing-fast indexing and are currently working on improving this. -::: - Chain reorganizations are handled automatically by HyperIndex, and are turned on by default. To turn this feature off, you can set the ```rollback_on_reorg``` flag in your config.yaml to ```false```: @@ -33,9 +29,4 @@ Important notes regarding rollbacks and reorgs: - Reorg detection is guaranteed when indexing from a [HyperSync](/docs/HyperIndex/Advanced/hypersync.md) as the data source. However, indexing from a [custom RPC](/docs/HyperIndex/Advanced/rpc-sync.md) as a data source may have edge cases where reorgs can occur undetected. - All entities defined in your schema and set/read in your handlers will be managed and rolled back in the event of a reorg. However, any additional side effects or caching used in your handlers cannot be accounted for. - -:::info -Before Envio version V2.1.2, handling chain reorgs were turned on by default. Conversely, it's ```true``` by default if the reorg feature is not explicitly turned off in the config.yaml. In V2.1.3 and onwards, chain reorgs for indexers generated using the [quickstart](/docs/HyperIndex/contract-import.md) will be turned off by default with the following flag `rollback_on_reorg: false` -::: - --- diff --git a/docs/HyperIndex/Guides/configuration-file.mdx b/docs/HyperIndex/Guides/configuration-file.mdx index 7c92daae..4982ad43 100644 --- a/docs/HyperIndex/Guides/configuration-file.mdx +++ b/docs/HyperIndex/Guides/configuration-file.mdx @@ -116,8 +116,11 @@ events: - event: "Transfer(address indexed from, address indexed to, uint256 value)" field_selection: transaction_fields: - - "to" - - "from" + - "hash" + - "transactionIndex" + - "gasUsed" + block_fields: + - "parentHash" ``` ## Environment Variables Interpolation diff --git a/docs/HyperIndex/Guides/event-handlers.mdx b/docs/HyperIndex/Guides/event-handlers.mdx index fe3893e9..40836e21 100644 --- a/docs/HyperIndex/Guides/event-handlers.mdx +++ b/docs/HyperIndex/Guides/event-handlers.mdx @@ -29,7 +29,7 @@ Each event that you want to process requires that a handler be registered. These Handler functions are called via: - + ```typescript import { } from "generated"; @@ -40,7 +40,7 @@ import { } from "generated"; ``` - + ```javascript const { } = require("generated"); @@ -51,7 +51,7 @@ const { } = require("generated"); ``` - + ```rescript Handlers...handler(async ({ event, context }) => { @@ -124,6 +124,8 @@ It is recommended to add `# yaml-language-server: $schema=./node_modules/envio/e ### Context +#### Get entity + In your handler functions, you can access entities in the database via the asynchronous `get` function as shown below: ```javascript @@ -134,6 +136,8 @@ The context also contains some logging functions that include the context automa > Dev note: 📢 For indexers built using `ReScript`, use a lowercase for the first letter of `entityName` when accessing it via context (i.e., `context.user` instead of `context.User`). +#### Modify entity + In addition to the `get` function, which is a read-only action, two write actions are provided in the context: - `set` @@ -153,10 +157,76 @@ context..deleteUnsafe(.id); The `set` method is used to either create an entity or to update an existing entity with the values defined in the `entityObject`. The `deleteUnsafe` method is an experimental feature that allows you to remove an entity with a particular ID from the database and indexer memory. This is an **unsafe** function since there may be unexpected repercussions when a deleted entity is linked to another entity. It is your responsibility to delete/fix these references manually. +#### Update entity field + +We don't have an `update` function in the context, but you can update an entity field by using the `set` function as shown below: + + + + + +```javascript +const poolManager = await context.PoolManager.get( + `${event.chainId}_${event.srcAddress}` +); +if (poolManager) { + context.PoolManager.set({ + ...poolManager, + txCount: poolManager.txCount + 1n, + totalValueLockedETH: poolManager.totalValueLockedETH + .minus(currentPoolTvlETH) + .plus(pool.totalValueLockedETH), + }) +} +``` + + + + +```typescript +const poolManager = await context.PoolManager.get( + `${event.chainId}_${event.srcAddress}` +); +if (poolManager) { + context.PoolManager.set({ + ...poolManager, + txCount: poolManager.txCount + 1n, + totalValueLockedETH: poolManager.totalValueLockedETH + .minus(currentPoolTvlETH) + .plus(pool.totalValueLockedETH), + }) +} +``` + + + + +```rescript +let poolManager = await context.PoolManager.get( + `${event.chainId}_${event.srcAddress}` +); +poolManager->Option.forEach(poolManager => { + context.PoolManager.set({ + ...poolManager, + txCount: poolManager.txCount + 1n, + totalValueLockedETH: poolManager.totalValueLockedETH + .minus(currentPoolTvlETH) + .plus(pool.totalValueLockedETH), + }) +}) +``` + + + + +:::note +For performance concerns related to `get` function calls in your handlers, refer to the [Benchmarking](/benchmarking) and [Loaders](/loaders) guides. These resources provide insights and solutions for optimizing performance. +::: + ### Example of Registering a Handler Function for the `NewGreeting` Event - + ```javascript let { Greeter } = require("generated"); @@ -183,7 +253,7 @@ Greeter.NewGreeting.handler(async ({ event, context }) => { ``` - + ```typescript import { Greeter, User } from "generated"; @@ -213,7 +283,7 @@ Greeter.NewGreeting.handler(async ({ event, context }) => { ``` - + ```rescript open Types @@ -264,7 +334,7 @@ It is a more advanced topic and can be covered in its section. We expose the `config.yaml` data in the handler via `getConfigByChainId`. The below code snippets show how to access the `config.yaml` data in the handler and the available data: - + ```javascript let { getConfigByChainId } = require("../generated/src/ConfigYAML.bs.js"); @@ -275,7 +345,7 @@ Greeter.NewGreeting.handler(async ({ event, context }) => { ``` - + ```typescript import { getConfigByChainId } from "../generated/src/ConfigYAML.gen"; @@ -286,7 +356,7 @@ Greeter.NewGreeting.handler(async ({ event, context }) => { ``` - + ```rescript open Types diff --git a/docs/HyperIndex/supported-networks/any-evm-with-rpc.md b/docs/HyperIndex/supported-networks/any-evm-with-rpc.md index 135063b2..0b80f78b 100644 --- a/docs/HyperIndex/supported-networks/any-evm-with-rpc.md +++ b/docs/HyperIndex/supported-networks/any-evm-with-rpc.md @@ -37,9 +37,9 @@ networks: Can’t find what you’re looking for or need support? Reach out to us on [Discord](https://discord.com/invite/Q9qt8gZ2fX); we’re always happy to help! :::info -the backbone of hyperindex’s blazing-fast indexing speed lies in using hypersync as a more performant and cost-effective data source to rpc for data retrieval. while rpcs are functional, and can be used in hyperindex as a data source, they are far from efficient when it comes to querying large amounts of data (a time-consuming and resource-intensive endeavour). +The backbone of HyperIndex’s blazing-fast indexing speed lies in using HyperSync as a more performant and cost-effective data source to RPC for data retrieval. While RPCs are functional, and can be used in HyperIndex as a data source, they are far from efficient when it comes to querying large amounts of data (a time-consuming and resource-intensive endeavour). -hypersync is significantly faster and more cost-effective than traditional rpc methods, allowing the retrieval of multiple blocks at once, and enabling sync speeds up to 1000x faster than rpc. +HyperSync is significantly faster and more cost-effective than traditional RPC methods, allowing the retrieval of multiple blocks at once, and enabling sync speeds up to 1000x faster than RPC. ::: --- diff --git a/docs/HyperIndex/supported-networks/index.md b/docs/HyperIndex/supported-networks/index.md index f2cb93d9..174a6e8a 100644 --- a/docs/HyperIndex/supported-networks/index.md +++ b/docs/HyperIndex/supported-networks/index.md @@ -10,9 +10,9 @@ HyperIndex natively supports indexing any EVM blockchain out of the box. As a de HyperIndex also supports data indexing on [Fuel](/docs/HyperIndex/fuel/fuel.md). :::info -the backbone of hyperindex’s blazing-fast indexing speed lies in using hypersync as a more performant and cost-effective data source to rpc for data retrieval. while rpcs are functional, and can be used in hyperindex as a data source, they are far from efficient when it comes to querying large amounts of data (a time-consuming and resource-intensive endeavour). +The backbone of HyperIndex’s blazing-fast indexing speed lies in using HyperSync as a more performant and cost-effective data source to RPC for data retrieval. While RPCs are functional, and can be used in HyperIndex as a data source, they are far from efficient when it comes to querying large amounts of data (a time-consuming and resource-intensive endeavour). -hypersync is significantly faster and more cost-effective than traditional rpc methods, allowing the retrieval of multiple blocks at once, and enabling sync speeds up to 1000x faster than rpc. +HyperSync is significantly faster and more cost-effective than traditional RPC methods, allowing the retrieval of multiple blocks at once, and enabling sync speeds up to 1000x faster than RPC. ::: If a [network is supported](/docs/HyperSync/hypersync-supported-networks) on HyperSync, then HyperSync is used by default as the data source. This means developers don't additionally need to worry about RPCs, rate-limiting, etc. This is especially valuable for multi-chain apps. From 84164d7d25bd15405175a7c0d45d22abd2688fc2 Mon Sep 17 00:00:00 2001 From: Dmitry Zakharov Date: Wed, 5 Mar 2025 17:05:13 +0400 Subject: [PATCH 2/2] Fix links --- docs/HyperIndex/Guides/event-handlers.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/HyperIndex/Guides/event-handlers.mdx b/docs/HyperIndex/Guides/event-handlers.mdx index 40836e21..826da91d 100644 --- a/docs/HyperIndex/Guides/event-handlers.mdx +++ b/docs/HyperIndex/Guides/event-handlers.mdx @@ -220,7 +220,7 @@ poolManager->Option.forEach(poolManager => { :::note -For performance concerns related to `get` function calls in your handlers, refer to the [Benchmarking](/benchmarking) and [Loaders](/loaders) guides. These resources provide insights and solutions for optimizing performance. +For performance concerns related to `get` function calls in your handlers, refer to the [Benchmarking](/docs/HyperIndex/benchmarking) and [Loaders](/docs/HyperIndex/loaders) guides. These resources provide insights and solutions for optimizing performance. ::: ### Example of Registering a Handler Function for the `NewGreeting` Event