自动化历史状态跟踪
自动化历史状态跟踪
背景
SubQuery 允许您从 Substrate, Avalanche 和其他网络索引您想要的数据。 目前,SubQuery是一个可变的数据存储,您可以在那里附加、更新、删除, 或以其他方式更改在 SubQuery 索引的数据集中已保存的实体。 由于SubQuery索引每个区块,每个实体的状态可以根据您的项目逻辑更新或删除。
用于索引账户余额的基本SubQuery项目可能有一个看起来像以下的实体。
type Person @entity {
id: ID!
type Person @entity {
id: ID!
accounts: [Account]
}
type Account @entity {
id: ID!
publicAddress: String!
}
publicAddress: String!
} # Alice's account address
balance: BigInt
transfers: [Transfer]
}
在上述示例中,Alice的DOT 平衡不断变化,并随着我们索引数据而变化。 账户
实体将更改 余额
属性。 一个基本的 SubQuery 项目,将帐户余额索引将丢失这个历史数据,并且只能存储当前索引块高度的状态。 例如,如果我们目前正在索引区块100,数据库中的数据只能代表Alice在第100区块上的帐户状态。
然后我们面临一个问题。 假定将数据索引到第200项时发生变化,我们如何查询第100项数据的状态?
自动化历史状态跟踪
SubQuery 现在实现所有新项目的历史状态跟踪自动化。 您可以在任何区块高度自动查询您的 SubQuery 项目的状态。 这意味着您可以建立允许用户返回的应用程序。 或显示您的数据状态如何随着时间的推移而变化。
简而言之,当您创建、更新或删除任何SubQuery实体时,我们将先前的状态存储在它有效的区块范围。 然后您可以使用相同的 GraphQL 端点和 API 从特定区块高度查询数据。
启用这个
对于至少以 @subql/node@1.1.1
和 @subql/query1.1.0
开始的所有新项目,此功能默认启用。 如果您想要将其添加到您现有的项目中, 更新 @subql/node
and @subql/quy
然后用一个干净的数据库重建你的项目。
如果您想要出于任何原因禁用此功能,您可以在 subql-node
设置 --disable-historical=true
参数。
启动时,此功能的当前状态将被打印到控制台(历史状态已启用
)。
If you are running your project locally using subql-node
or subql-node-<network>
, make sure you enable the pg_extension btree_gist
You can run the following SQL query:
CREATE EXTENSION IF NOT EXISTS btree_gist;
查询历史状态
GraphQL实体过滤器上有一个特殊(可选)属性,名为 blockheight
。 如果您省略了此属性,SubQuery将查询当前区块高度的实体状态。
请查看我们的一个示例项目: RMRK NFT。
要在方块高度500,000,000,000时查询RMRK NFT的所有者,请添加如下方块高度参数:
query {
nFTEntities(first: 5, blockHeight: "5000000") {
nodes {
name
currentOwner
}
}
}
要查询这些RMRK NFT集合的所有者在最晚的区块高度时,省略下面显示的区块高度参数。
query {
nFTEntities(first: 5) {
nodes {
name
currentOwner
}
}
}
Reindexing with Historical Data
When you enable Automated Historical State Tracking, you can benefit from on demand partial reindexing from certain block heights. 示例
- You can subscribe to new events, transactions, or assets in your manifest file, then backtrack to when they were deployed and start reindexing from that block
- You could update your mapping files to add new logic to deal with a runtime change, and then backtrack to the block where the runtime change was deployed.
- Coming Soon: You can update your schema and reindex from a certain block height to reflect those changes
You should see the new -- reindex command in Command Line Flags to learn more about how to use this new feature.