You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: pages/en/delegating.mdx
+2-2Lines changed: 2 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -83,13 +83,13 @@ Imagine an Indexer has 100,000,000 GRT delegated to them, and their capacity is
83
83
84
84
Therefore a Delegator should always consider the Delegation Capacity of an Indexer, and factor it into their decision making.
85
85
86
-
## Delegator FAQs and Bugs
86
+
## Delegator FAQs and Bugs
87
87
88
88
### MetaMask "Pending Transaction" Bug
89
89
90
90
**When I try to delegate my transaction in MetaMask appears as "Pending" or "Queued" for longer than expected. What should I do?**
91
91
92
-
At times, attempts to delegate to indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts. For example, a user may attempt to delegate with an insufficient gas fee relative to the current prices, resulting in the transaction attempt displaying as "Pending" in their MetaMask wallet for 15+ minutes. When this occurs, subsequent transactions can be attempted by a user, but these will not be processed until the initial transaction is mined, as transactions for an address must be processed in order. In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful. A simpler resolution to this bug is restarting the browsesr (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users that have encountered this issue and have reported successful transactions after restarting their browser and attempting to delegate.
92
+
At times, attempts to delegate to indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts. For example, a user may attempt to delegate with an insufficient gas fee relative to the current prices, resulting in the transaction attempt displaying as "Pending" in their MetaMask wallet for 15+ minutes. When this occurs, subsequent transactions can be attempted by a user, but these will not be processed until the initial transaction is mined, as transactions for an address must be processed in order. In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful. A simpler resolution to this bug is restarting the browsesr (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users that have encountered this issue and have reported successful transactions after restarting their browser and attempting to delegate.
Copy file name to clipboardExpand all lines: pages/en/developer/assemblyscript-api.mdx
+2-2Lines changed: 2 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -45,7 +45,7 @@ The `apiVersion` in the subgraph manifest specifies the mapping API version whic
45
45
46
46
| Version | Release notes |
47
47
| :-: | --- |
48
-
| 0.0.7 | Added `TransactionReceipt` and `Log` classes to the Ethereum types<br />Added `receipt` field to the Ethereum Event object|
48
+
| 0.0.7 | Added `TransactionReceipt` and `Log` classes to the Ethereum types<br />Added `receipt` field to the Ethereum Event object|
49
49
| 0.0.6 | Added `nonce` field to the Ethereum Transaction object<br />Added `baseFeePerGas` to the Ethereum Block object |
50
50
| 0.0.5 | AssemblyScript upgraded to version 0.19.10 (this includes breaking changes, please see the [`Migration Guide`](/developer/assemblyscript-migration-guide))<br />`ethereum.transaction.gasUsed` renamed to `ethereum.transaction.gasLimit`|
51
51
| 0.0.4 | Added `functionSignature` field to the Ethereum SmartContractCall object |
Copy file name to clipboardExpand all lines: pages/en/developer/create-subgraph-hosted.mdx
+1-3Lines changed: 1 addition & 3 deletions
Original file line number
Diff line number
Diff line change
@@ -168,7 +168,6 @@ The schema for your subgraph is in the file `schema.graphql`. GraphQL schemas ar
168
168
169
169
Before defining entities, it is important to take a step back and think about how your data is structured and linked. All queries will be made against the data model defined in the subgraph schema and the entities indexed by the subgraph. Because of this, it is good to define the subgraph schema in a way that matches the needs of your dapp. It may be useful to imagine entities as "objects containing data", rather than as events or functions.
170
170
171
-
172
171
With The Graph, you simply define entity types in `schema.graphql`, and Graph Node will generate top level fields for querying single instances and collections of that entity type. Each type that should be an entity is required to be annotated with an `@entity` directive. By default, entities are mutable, meaning that mappings can load existing entities, modify them and store a new version of that entity. Mutability comes at a price, and for entity types for which it is known that they will never be modified, for example, because they simply contain data extracted verbatim from the chain, it is recommended to mark them as immutable with `@entity(immutable: true)`. Mappings can make changes to immutable entities as long as those changes happen in the same block in which the entity was created. Immutable entities are much faster to write and to query, and should therefore be used whenever possible.
173
172
174
173
### Good Example
@@ -444,7 +443,7 @@ Supported language dictionaries:
444
443
| hu | Hungarian |
445
444
| it | Italian |
446
445
| no | Norwegian |
447
-
| pt | Portuguese |
446
+
| pt | Portuguese |
448
447
| ro | Romanian |
449
448
| ru | Russian |
450
449
| es | Spanish |
@@ -831,7 +830,6 @@ eventHandlers:
831
830
832
831
Inside the handler function, the receipt can be accessed in the `Event.receipt` field. When the `receipt` key is set to `false` or omitted in the manifest, a `null` value will be returned instead.
833
832
834
-
835
833
## Experimental features
836
834
837
835
Starting from `specVersion` `0.0.4`, subgraph features must be explicitly declared in the `features` section at the top level of the manifest file, using their `camelCase` name, as listed in the table below:
@@ -184,7 +184,6 @@ In addition, the following global filters are available as part of `where` argum
184
184
_change_block(number_gte: Int)
185
185
```
186
186
187
-
188
187
### Time-travel queries
189
188
190
189
You can query the state of your entities not just for the latest block, which is the by default, but also for an arbitrary block in the past. The block at which a query should happen can be specified either by its block number or its block hash by including a `block` argument in the toplevel fields of queries.
Copy file name to clipboardExpand all lines: pages/en/developer/matchstick.mdx
+49-38Lines changed: 49 additions & 38 deletions
Original file line number
Diff line number
Diff line change
@@ -33,22 +33,27 @@ sudo apt install postgresql
33
33
```
34
34
35
35
### WSL (Windows Subsystem for Linux)
36
-
You can use Matchstick on WSL both using the Docker approach and the binary approach. As WSL can be a bit tricky, here's a few tips in case you encounter issues like
36
+
37
+
You can use Matchstick on WSL both using the Docker approach and the binary approach. As WSL can be a bit tricky, here's a few tips in case you encounter issues like
Please make sure you're on a newer version of Node.js graph-cli doesn't support **v10.19.0** anymore, and that is still the default version for new Ubuntu images on WSL. For instance Matchstick is confirmed to be working on WSL with **v18.1.0**, you can switch to it either via **nvm** or if you update your global Node.js.
46
-
Don't forget to delete `node_modules` and to run `npm install` again after updating you nodejs!
47
-
Then, make sure you have **libpq** installed, you can do that by running
49
+
Please make sure you're on a newer version of Node.js graph-cli doesn't support **v10.19.0** anymore, and that is still the default version for new Ubuntu images on WSL. For instance Matchstick is confirmed to be working on WSL with **v18.1.0**, you can switch to it either via **nvm** or if you update your global Node.js. Don't forget to delete `node_modules` and to run `npm install` again after updating you nodejs! Then, make sure you have **libpq** installed, you can do that by running
50
+
48
51
```
49
52
sudo apt-get install libpq-dev
50
-
```
51
-
And finally, do not use `graph test` (which uses your global installation of graph-cli and for some reason that looks like it's broken on WSL currently), instead use `yarn test` or `npm run test` (that will use the local, project-level instance of graph-cli, which works like a charm. For that you would of course need to have a `"test"` script in your `package.json` file which can be something as simple as
53
+
```
54
+
55
+
And finally, do not use `graph test` (which uses your global installation of graph-cli and for some reason that looks like it's broken on WSL currently), instead use `yarn test` or `npm run test` (that will use the local, project-level instance of graph-cli, which works like a charm. For that you would of course need to have a `"test"` script in your `package.json` file which can be something as simple as
56
+
52
57
```json
53
58
{
54
59
"name": "demo-subgraph",
@@ -67,26 +72,30 @@ And finally, do not use `graph test` (which uses your global installation of gra
67
72
68
73
### Usage
69
74
70
-
To use **Matchstick** in your subgraph project just open up a terminal, navigate to the root folder of your project and simply run `graph test [options] <datasource>` - it downloads the latest **Matchstick** binary and runs the specified test or all tests in a test folder (or all existing tests if no datasource flag is specified).
75
+
To use **Matchstick** in your subgraph project just open up a terminal, navigate to the root folder of your project and simply run `graph test [options] <datasource>` - it downloads the latest **Matchstick** binary and runs the specified test or all tests in a test folder (or all existing tests if no datasource flag is specified).
71
76
72
77
### CLI options
73
78
74
79
This will run all tests in the test folder:
80
+
75
81
```sh
76
82
graph test
77
83
```
78
84
79
85
This will run a test named gravity.test.ts and/or all test inside of a folder named gravity:
86
+
80
87
```sh
81
-
graph test gravity
88
+
graph test gravity
82
89
```
83
90
84
91
This will run only that specific test file:
92
+
85
93
```sh
86
94
graph test path/to/file.test.ts
87
95
```
88
96
89
97
**Options:**
98
+
90
99
```sh
91
100
-c, --coverage Run the tests in coverage mode
92
101
-d, --docker Run the tests in a docker container (Note: Please execute from the root folder of the subgraph)
Runs a code block before any of the tests in the file. If `beforeAll` is declared inside of a `describe` block, it runs at the beginning of that `describe` block.
208
219
209
220
Examples:
210
221
211
-
Code inside `beforeAll` will execute once before *all* tests in the file.
222
+
Code inside `beforeAll` will execute once before _all_ tests in the file.
212
223
213
224
```typescript
214
225
import { describe, test, beforeAll } from "matchstick-as/assembly/index"
Runs a code block after all of the tests in the file. If `afterAll` is declared inside of a `describe` block, it runs at the end of that `describe` block.
267
279
268
280
Example:
269
281
270
-
Code inside `afterAll` will execute once after *all* tests in the file.
282
+
Code inside `afterAll` will execute once after _all_ tests in the file.
271
283
272
284
```typescript
273
285
import { describe, test, afterAll } from "matchstick-as/assembly/index"
Testing dynamic data sources can be be done by mocking the return value of the `context()`, `address()` and `network()` functions of the dataSource namespace. These functions currently return the following: `context()` - returns an empty entity (DataSourceContext), `address()` - returns `0x0000000000000000000000000000000000000000`, `network()` - returns `mainnet`. The `create(...)` and `createWithContext(...)` functions are mocked to do nothing so they don't need to be called in the tests at all. Changes to the return values can be done through the functions of the `dataSourceMock` namespace in `matchstick-as` (version 0.3.0+).
930
+
Testing dynamic data sources can be be done by mocking the return value of the `context()`, `address()` and `network()` functions of the dataSource namespace. These functions currently return the following: `context()` - returns an empty entity (DataSourceContext), `address()` - returns `0x0000000000000000000000000000000000000000`, `network()` - returns `mainnet`. The `create(...)` and `createWithContext(...)` functions are mocked to do nothing so they don't need to be called in the tests at all. Changes to the return values can be done through the functions of the `dataSourceMock` namespace in `matchstick-as` (version 0.3.0+).
920
931
921
-
Example below:
932
+
Example below:
922
933
923
934
First we have the following event handler (which has been intentionally repurposed to showcase datasource mocking):
Copy file name to clipboardExpand all lines: pages/en/developer/publish-subgraph.mdx
+1-1Lines changed: 1 addition & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -24,4 +24,4 @@ Subgraphs can be published to the decentralized network directly from the Subgra
24
24
25
25
### Updating metadata for a published subgraph
26
26
27
-
Once your subgraph has been published to the decentralized network, you can modify the metadata at any time by making the update in the Subgraph Studio dashboard of the subgraph. After saving the changes and publishing your updates to the network, they will be reflected in The Graph Explorer. This won’t create a new version, as your deployment hasn’t changed.
27
+
Once your subgraph has been published to the decentralized network, you can modify the metadata at any time by making the update in the Subgraph Studio dashboard of the subgraph. After saving the changes and publishing your updates to the network, they will be reflected in The Graph Explorer. This won’t create a new version, as your deployment hasn’t changed.
0 commit comments