From 8f7e72d510750718cc301dddc06380c30b50fe2d Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Tue, 29 Oct 2024 07:02:57 +0100 Subject: [PATCH] Fix typos (#564) * fix typos * fix typo * fix typos * fix typo * fix typos * fix typos * fix typos * fix typos --- docs/indexer/build/cosmos-evm.md | 2 +- docs/indexer/build/graph-migration.md | 14 +++++++------- docs/indexer/build/graphql.md | 2 +- docs/indexer/build/install.md | 4 ++-- docs/indexer/build/introduction.md | 8 ++++---- docs/indexer/build/multi-chain.md | 4 ++-- docs/indexer/build/project-upgrades.md | 4 ++-- docs/indexer/build/substrate-evm.md | 6 +++--- 8 files changed, 22 insertions(+), 22 deletions(-) diff --git a/docs/indexer/build/cosmos-evm.md b/docs/indexer/build/cosmos-evm.md index 414708c7984..ec2c0257972 100644 --- a/docs/indexer/build/cosmos-evm.md +++ b/docs/indexer/build/cosmos-evm.md @@ -14,7 +14,7 @@ This document goes into detail about how to use the Ethermint Cosmos RPCs (rathe 1. Add the custom datasource as a dependency: -- Create a new project from an EVM template though `subql init` OR +- Create a new project from an EVM template through `subql init` OR - For existing projects, `yarn add @subql/ethermint-evm-processor` or `npm i @subql/ethermint-evm-processor`. 2. Add a custom data source as described below. diff --git a/docs/indexer/build/graph-migration.md b/docs/indexer/build/graph-migration.md index 7c2644ecc09..9792241409f 100644 --- a/docs/indexer/build/graph-migration.md +++ b/docs/indexer/build/graph-migration.md @@ -4,7 +4,7 @@ SubQuery provides a superior indexing SDK to Subgraphs and this document outlines the migration process. However SubQuery also provides a one-step migration for **hosting** your Subgraphs on The Graph’s hosted service / decentralised network, or other Subgraph hosting service. This is a drop-in replacement with the following benefits: -- A enterprise level hosting platform with targeted 99.9% uptime +- An enterprise level hosting platform with targeted 99.9% uptime - Blue/green hot-swap deployments of subgraphs, allowing for seamless updates on your frontend - Project alert notification of outages and indexing issues - A team who monitors your Subgraphs 24/7, with potential for service level agreements real time support with your team @@ -22,7 +22,7 @@ SubQuery provides a superior developer experience to The Graph, while maintainin - **Wider chain support** - SubQuery supports all EVM networks, as well as many other non-EVM networks, like Cosmos, Polkadot, Algorand, NEAR, and more - **Lightweight** - SubQuery is designed to connect to external public RPC endpoints, you don't need to run an archive node locally when developing - **Multi-chain indexing support** - SubQuery allows you to index data from across different layer-1 networks into the same database, this allows you to query a single endpoint to get data for all supported networks. [Read more](../build/multi-chain.md). -- **More control** - A large library of [command line parameters](../run_publish/references.md) to all you to run, monitor, and optimise your locally hosted project +- **More control** - A large library of [command line parameters](../run_publish/references.md) to allow you to run, monitor, and optimise your locally hosted project - **Managed Service hosting** - We have no plans to sunset our [Managed Service](https://managedservice.subquery.network), which provides enterprise-level infrastructure hosting and handles over hundreds of millions of requests each day - **A decentralised network supporting all chains** - Our [decentralised network](https://app.subquery.network) supports all chains that SubQuery support, there is no _second-class_ chain support in the SubQuery ecosystem - **The same query API** - We support a Subgraph compatible query service, providing the same GraphQL API that you are currently using. @@ -53,7 +53,7 @@ This is the recommended process that we use at SubQuery whenever we migrate proj Firstly, use the SubQuery CLI tool to migrate an existing SubGraph by using the `subql migrate` command. This will: -- Intialise a new SubQuery project in your chosen directory for the matching target chain +- Initialise a new SubQuery project in your chosen directory for the matching target chain - Copy over basic information like project name and other metadata - Enable ts strict mode to assist you in identifying potential issues when migrating your project. - Migrate the `schema.graphql` to be compatible with SubQuery, there is a chance you will need to edit this after migration to fine-tune the migrated code. @@ -83,11 +83,11 @@ Once this is done, follow along and complete the remaining steps: - Store operations are asynchronous, e.g. `.load(id)` should be replaced by `await .get(id)` and `.save()` to `await .save()` (note the `await`). - With strict mode, you must construct new entities with all the required properties. You may want to replace `new (id)` with `.create({ ... })` - [More info](#mapping). -5. Either use the [Subgraph compatibale query service](../run_publish/query/subgraph.md), or test and update your clients to follow the SubQuery native GraphQL API. There are some minor and you can take advantage of additional features. [More info](#graphql-query-differences) +5. Either use the [Subgraph compatible query service](../run_publish/query/subgraph.md), or test and update your clients to follow the SubQuery native GraphQL API. There are some minor and you can take advantage of additional features. [More info](#graphql-query-differences) ### Differences in the GraphQL Schema -Both SubGraphs and SubQuery projects use the same `schema.graphql` to define entities and includes both similar [scalar types](./graphql.md#supported-scalar-types) as well as [full text search](./graphql.md#full-text-search). +Both SubGraphs and SubQuery projects use the same `schema.graphql` to define entities and include both similar [scalar types](./graphql.md#supported-scalar-types) as well as [full text search](./graphql.md#full-text-search). Visit this [full documentation for `schema.graphql`](./graphql.md). **You can copy this file from your SubGraph to your SubQuery project in most cases.** @@ -162,7 +162,7 @@ const project: EthereumProject = { version: "0.0.1", name: "subquery-example-gravatar", description: - "This project can be use as a starting point for developing your new Ethereum SubQuery project, it indexes all Gravatars on Ethereum", + "This project can be used as a starting point for developing your new Ethereum SubQuery project, it indexes all Gravatars on Ethereum", repository: "https://github.com/subquery/ethereum-subql-starter", runner: { node: { @@ -231,7 +231,7 @@ runner: query: name: "@subql/query" version: "*" -description: "This project can be use as a starting point for developing your new Ethereum SubQuery project, it indexes all Gravatars on Ethereum" +description: "This project can be used as a starting point for developing your new Ethereum SubQuery project, it indexes all Gravatars on Ethereum" repository: "https://github.com/subquery/eth-gravatar" schema: diff --git a/docs/indexer/build/graphql.md b/docs/indexer/build/graphql.md index cf3f0217053..decee0c352d 100644 --- a/docs/indexer/build/graphql.md +++ b/docs/indexer/build/graphql.md @@ -71,7 +71,7 @@ npm run-script codegen ::: -All entites can be imported from the following directory after codegen: +All entities can be imported from the following directory after codegen: ```ts import { GraphQLEntity1, GraphQLEntity2 } from "../types"; diff --git a/docs/indexer/build/install.md b/docs/indexer/build/install.md index 713b0168666..dc7f524e75b 100644 --- a/docs/indexer/build/install.md +++ b/docs/indexer/build/install.md @@ -23,7 +23,7 @@ yarn global add @subql/cli ::: -You can then run help to see available commands and usage provide by CLI: +You can then run help to see available commands and usage provided by CLI: ```shell subql --help @@ -50,7 +50,7 @@ yarn global add @subql/node ::: -Once installed, you can can start a node with: +Once installed, you can start a node with: ```shell subql-node diff --git a/docs/indexer/build/introduction.md b/docs/indexer/build/introduction.md index 7d0df0077b2..2d3ad23bf55 100644 --- a/docs/indexer/build/introduction.md +++ b/docs/indexer/build/introduction.md @@ -46,7 +46,7 @@ Scaffolding saves time during SubQuery project creation by automatically generat When you are initialising a new project using the `subql init` command, SubQuery will give you the option to set up a scaffolded SubQuery project based on your JSON ABI. -If you have select an compatible network type (EVM), it will prompt +If you have select a compatible network type (EVM), it will prompt ```shell ? Do you want to generate scaffolding with an existing abi contract? @@ -173,7 +173,7 @@ const project: EthereumProject = { version: "0.0.1", name: "ethereum-subql-starter", description: - "This project can be use as a starting point for developing your new Ethereum SubQuery project", + "This project can be used as a starting point for developing your new Ethereum SubQuery project", runner: { node: { name: "@subql/node-ethereum", @@ -269,7 +269,7 @@ The `schema.graphql` file outlines the various GraphQL schemas. The structure of 3. [Entity Relationships](./graphql.md#entity-relationships): An entity often has nested relationships with other entities. Setting the field value to another entity name will define a relationship between these two entities. 4. [Indexing](./graphql.md#indexing-by-non-primary-key-field): Enhance query performance by implementing the @index annotation on a non-primary-key field. -Here's an example of what your GraphQL Here is an example of a schema which implements all of these recommendations, as well a relationship of many-to-many: +Here's an example of what your GraphQL Here is an example of a schema which implements all of these recommendations, as well as a relationship of many-to-many: ::: tip @@ -333,7 +333,7 @@ npm run-script codegen ::: -This will create a new directory (or update the existing) `src/types` which contain generated entity classes for each type you have defined previously in `schema.graphql`. These classes provide type-safe entity loading, read and write access to entity fields - see more about this process in [the GraphQL Schema](../build/graphql.md). All entities can be imported from the following directory: +This will create a new directory (or update the existing) `src/types` which contains generated entity classes for each type you have defined previously in `schema.graphql`. These classes provide type-safe entity loading, read and write access to entity fields - see more about this process in [the GraphQL Schema](../build/graphql.md). All entities can be imported from the following directory: ```ts import { GraphQLEntity1, GraphQLEntity2 } from "../types"; diff --git a/docs/indexer/build/multi-chain.md b/docs/indexer/build/multi-chain.md index a235745f4e9..0e886370961 100644 --- a/docs/indexer/build/multi-chain.md +++ b/docs/indexer/build/multi-chain.md @@ -111,7 +111,7 @@ Use `subql publish` command to publish all the projects listed in the `subquery- The repository for this example can be found [here](https://github.com/subquery/subql-starter/tree/main/Multi-chain/transfers), it is an example of a multichain project that indexes multiple networks (in this case Polkadot and Kusama) into the same database. -A modified `docker-compose.yaml` file has been included, with two subql/node images, one for each network being indexed. You will notice that that each image maps to a seperate manifest file (see [command line references](../run_publish/references.md)). +A modified `docker-compose.yaml` file has been included, with two subql/node images, one for each network being indexed. You will notice that that each image maps to a separate manifest file (see [command line references](../run_publish/references.md)). This multi-chain project can be started regularly by following the [Readme.md](https://github.com/subquery/subql-starter/tree/main/Multi-chain/transfers/blob/main/README.md). @@ -173,7 +173,7 @@ In many cases, you will have a completely different set of mapping handlers to d ## Cross-Chain Race Conditions -If you are intending to mutate data across chain, e.g. an action in one network will affect a entity saved from another, then please be aware that SubQuery provides no guarantees of cross-chain ordering. +If you are intending to mutate data across chain, e.g. an action in one network will affect an entity saved from another, then please be aware that SubQuery provides no guarantees of cross-chain ordering. For example, one chain may index much faster than the other, and when indexing a cross-chain transaction, indexer B may encounter the receipt of this transaction on chain B well before the indexer A encounters that the transaction has been sent on chain A. diff --git a/docs/indexer/build/project-upgrades.md b/docs/indexer/build/project-upgrades.md index e81409bcbc4..78a7001c156 100644 --- a/docs/indexer/build/project-upgrades.md +++ b/docs/indexer/build/project-upgrades.md @@ -24,7 +24,7 @@ When defining a project upgrade, you clone the project manifest (`project.ts`), { parent: { // The block height the parent project will run until before switching to the current project. - // `block` is also supported but deprectated, it behaves as an alias for `untilBlock` + // `block` is also supported but deprecated, it behaves as an alias for `untilBlock` untilBlock: 1050, // The CID of your existing project that you wish to replace reference: "QmXw6FN6eScxvYXYceuCjKMpqmnuCxwY3Cx4HPhDXgUWe5", @@ -46,7 +46,7 @@ This feature is still in beta Schema migrations allow you to make updates to your GraphQL schema, and the database tables, during the middle of indexing at a specific block height. -When a project upgrade is executed with valid schema migrations, it will compare your current schema with the schema provided in the latest version (the one you are upgrading too), and attempt to make non-destructive changes your database. +When a project upgrade is executed with valid schema migrations, it will compare your current schema with the schema provided in the latest version (the one you are upgrading to), and attempt to make non-destructive changes to your database. ::: warning If you re-run a previous version of your project accidentally, SubQuery will attempt to downgrade changes to your schema. diff --git a/docs/indexer/build/substrate-evm.md b/docs/indexer/build/substrate-evm.md index b3250bbbe4e..1b3fb7249f7 100644 --- a/docs/indexer/build/substrate-evm.md +++ b/docs/indexer/build/substrate-evm.md @@ -38,7 +38,7 @@ Theoretically all the following networks (and more) should also be supported sin 1. Add the custom datasource as a dependency: -- Create a new project from an EVM template though `subql init` OR +- Create a new project from an EVM template through `subql init` OR - For existing projects, `yarn add -D @subql/frontier-evm-processor` or `npm i @subql/acala-evm-processor --save-dev`. 2. Add exports to your `package.json` like below in order for IPFS deployments to work @@ -103,7 +103,7 @@ Works in the same way as [substrate/CallHandler](../build/mapping/polkadot.md#ca | Field | Type | Required | Description | | ------ | ------------------------------------------------------- | -------- | ------------------------------------------- | -| kind | `substrate/FrontierEvmCall` or `substrate/AcalaEvmCall` | Yes | Specifies that this is an Call type handler | +| kind | `substrate/FrontierEvmCall` or `substrate/AcalaEvmCall` | Yes | Specifies that this is a Call type handler | | filter | [Call Filter](substrate-evm.md#call-filters) | No | Filter the data source to execute | ### Call Filters @@ -352,7 +352,7 @@ This is an extract from the `project.ts` manifest file. ## Querying contracts -`@subql/frontier-evm-processor` is the only package that currently allows this. It provides [FrontierEthProvider](https://github.com/subquery/datasource-processors/blob/697d63f5a9c978f3e231e0bb4975f05213077d23/packages/frontier-evm/src/frontierEthProvider.ts#L75) which implements an [Ethers Provider](https://docs.ethers.io/v5/api/providers/provider/), this implementation is restricted to only support methods for the current height. You can pass it to a contract instance in order to query contract state at the hight currently being indexed. +`@subql/frontier-evm-processor` is the only package that currently allows this. It provides [FrontierEthProvider](https://github.com/subquery/datasource-processors/blob/697d63f5a9c978f3e231e0bb4975f05213077d23/packages/frontier-evm/src/frontierEthProvider.ts#L75) which implements an [Ethers Provider](https://docs.ethers.io/v5/api/providers/provider/), this implementation is restricted to only support methods for the current height. You can pass it to a contract instance in order to query contract state at the height currently being indexed. ## Known Limitations