Автоматичне Відстеження Історичного Стану
Автоматичне Відстеження Історичного Стану
Фон
SubQuery дозволяє індексувати будь-які дані, які ви хочете отримати з Substrate, Avalanche та інших мереж. Зараз SubQuery працює як змінюване сховище даних, де ви можете додавати, оновлювати, видаляти або іншим чином змінювати що існує збережені об'єкти в наборі даних, який індексується SubQuery. Оскільки SubQuery індексує кожен блок, стан кожного об'єкта може бути оновлено або видалено в залежності від логіки вашого проєкту.
Базовий проєкт SubQuery, який індексує залишки на рахунках, може мати об'єкт, який виглядає наступним чином.
Введіть обліковий запис @entity {
id: ID! # Alice's account address
balance: BigInt
transfers: [Transfer]
}
У наведеному вище прикладі баланс DOT Аліси постійно змінюється, і в міру того, як ми індексуємо дані, властивість balance
по суті Account
буде змінюватися. Базовий проєкт SubQuery, який індексує залишки на рахунках, втратить ці Історичні дані й збереже тільки стан поточної висоти блоку індексації. Наприклад, якщо ми зараз індексуємо блок 100, дані в базі даних можуть представляти лише стан облікового запису Аліси в блоці 100.
Тоді ми стикаємося з проблемою. Припускаючи, що дані змінилися при індексації в блок 200, як ми можемо запитати стан даних в блоці 100?
Автоматичне Відстеження Історичного Стану
SubQuery тепер автоматизує відстеження історичного стану об'єктів для всіх нових проєктів. Ви можете автоматично запитувати стан вашого проєкту SubQuery на будь-якій висоті блоку. Це означає, що ви можете створювати додатки, які дозволяють користувачам повертатися в минуле або показувати, як стан ваших даних змінюється з плином часу.
Коротко кажучи, Коли ви створюєте, оновлюєте або видаляєте будь-який об'єкт SubQuery, ми зберігаємо попередній стан з діапазоном блоків, для якого він був дійсним. Потім ви можете запросити дані з певної висоти блоку, використовуючи ті ж кінцеві точки GraphQL і API.
Включення Цього
Ця функція включена за замовчуванням для всіх нових проєктів, розпочатих як мінімум з @subql/node@1.1.1
і @subql/query1.1.0
. Якщо ви хочете додати його до що існує проєкт, оновіть @subql/node
та @subql/query
, а потім переіндексуйте свій проєкту за допомогою чистої бази даних.
Якщо ви хочете вимкнути цю функцію з будь-якої причини, ви можете встановити параметр --disable-historical=true
на subql-node
.
При запуску поточний стан цієї функції виводиться на консоль (Historical state is enabled
).
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.
Щоб запросити власників RMRK NFTs з висотою блоку 5 000 000, додайте параметр blockHeight, як показано нижче:
query {
nFTEntities(first: 5, blockHeight: "5000000") {
nodes {
name
currentOwner
}
}
}
Щоб запросити власників цих колекцій RMRK NFTs з останньою висотою блоку, опустіть параметр blockHeight, як показано нижче.
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.