Манифест Файл
Манифест Файл
Файлът Manifest project.yaml може да се разглежда като входящата точка на вашия проект, той дефинира повечето подробности за това как SubQuery ще индексира и трансформира данните от веригата.
Манифестът може да бъде във формат YAML или JSON. В този документ ще използваме YAML във всички примери. По-долу е даден стандартен пример за основен project.yaml.
::: code-tabs @tab v0.2.0 yml specVersion: 0.2.0 name: example-project # version: 1.0.0 # Версия на проекта description: '' # Посочете името на проекта repository: 'https://github.com/subquery/subql-starter' # Git адрес на хранилището на вашия проект schema: file: ./schema.graphql # Местоположението на вашия файл със схема на GraphQL network: genesisHash: '0x91b171bb158e2d3848fa23a9f1c25182fb8e20313b2c1eb49219da7a70ce90c3' # Генезис хеш на мрежата endpoint: 'wss://polkadot.api.onfinality.io/public-ws' # По избор предоставете HTTP крайната точка на речник с пълна верига, за да ускорите обработката dictionary: 'https://api.subquery.network/sq/subquery/dictionary-polkadot' dataSources: - kind: substrate/Runtime startBlock: 1 # Това променя вашия начален блок за индексиране, задайте го по-високо, за да пропуснете първоначалните блокове с по-малко данни mapping: file: "./dist/index.js" handlers: - handler: handleBlock kind: substrate/BlockHandler - handler: handleEvent kind: substrate/EventHandler filter: #Filter is optional module: balances method: Deposit - handler: handleCall kind: substrate/CallHandler ```` @tab v0.0.1 yml specVersion: "0.0.1" description: '' # Описание на вашия проект repository: 'https://github.com/subquery/subql-starter' # Git адрес на хранилището на вашия проект schema: ./schema.graphql # Местоположението на вашия файл със схема на GraphQL network: endpoint: 'wss://polkadot.api.onfinality.io/public-ws' # По избор предоставете HTTP крайната точка на речник с пълна верига, за да ускорите обработката dictionary: 'https://api.subquery.network/sq/subquery/dictionary-polkadot' dataSources: - name: main kind: substrate/Runtime startBlock: 1 # Това променя вашия начален блок за индексиране, задайте го по-високо, за да пропуснете първоначалните блокове с по-малко данни mapping: handlers: - handler: handleBlock kind: substrate/BlockHandler - handler: handleEvent kind: substrate/EventHandler filter: #Филтърът е по избор, но се препоръчва за ускоряване на обработката на събития module: balances method: Deposit - handler: handleCall kind: substrate/CallHandler ```` :::
Мигриране от v0.0.1 към v0.2.0 upgrade
**Ако имате проект със specVersion v0.0.1, можете да използвате subql migrate за бързо ъпдейтване. Вижте тук за повече информация **
Под мрежа:
- Има ново**задължително поле **
genesisHash, което помага да се идентифицира използваната верига. - За v0.2.0 и по-нова версия, можете да свържете външен chaintype file, ако препращате към персонализирана верига.
Под Източници на данни:
- Може директно да свържете входната точка
index.jsза мапинг манипулатори. По подразбиране тозиindex.jsще се генерира отindex.tsпо време на процеса на изграждане. - Източниците на данни вече могат да бъдат или обикновен източник на данни по време на изпълнение, или персонализиран източник на данни.
CLI Опции
По подразбиране CLI ще генерира SubQuery проекти за версия v0.2.0 на спецификацията. Това поведение може да бъде прекратено, чрез стартиране на subql init --specVersion 0.0.1 PROJECT_NAME, въпреки че това не се препоръчва, тъй като проектът няма да се поддържа от хостваната SubQuery услуга в бъдеще
subql migrate може да се стартира в съществуващ проект, за да мигрира манифеста на проекта към най-новата версия.
USAGE $ subql init [PROJECTNAME]
АРГУМЕНТИ PROJECTNAME Дава име на началния проект
| Опции | Описание | | ----------------------- | --------------------------------------------------------------------------------------- | ----------------------------------------------------------- | | -f, --force | | | -l, --location=location | локална папка, в която да създадете проекта | | --install-dependencies | Инсталирайте и зависимостите | | --npm | Принудително използване на NPM вместо прежда, работи само с флаг install-dependencies | | --specVersion=0.0.1 | 0.2.0 [default: 0.2.0] | Версията на спецификацията, която ще се използва от проекта |
Обзор
Най-високо ниво спецификации
| Поле | v0.0.1 | v0.2.0 | Описание |
|---|---|---|---|
| specVersion | Низ | Низ | 0.0.1 or 0.2.0 - версия на спецификацията на файла на манифеста |
| name | 𐄂 | Низ | Име на проекта |
| version | 𐄂 | Низ | Версия на вашия проект |
| description | Низ | Низ | Описание на вашия проект |
| repository | Низ | Низ | Git адрес на хранилището на вашия проект |
| schema | Низ | Спецификация на схемата | Местоположението на вашия файл със схема на GraphQL |
| network | Мрежова спецификация | Мрежова спецификация | Подробности за мрежата, която трябва да бъде индексирана |
| dataSources | Спецификация на източника на данни | Спецификация на източника на данни |
Спецификация на схемата
| Поле | v0.0.1 | v0.2.0 | Описание |
|---|---|---|---|
| file | 𐄂 | String | Местоположението на вашия файл със схема на GraphQL |
Мрежова спецификация
| Поле | v0.0.1 | v0.2.0 | Описание |
|---|---|---|---|
| genesisHash | 𐄂 | Низ | Генезисният хеш на мрежата |
| endpoint | Низ | Низ | Дефинира wss или ws крайната точка на блокчейна, която да бъде индексирана - Това трябва да е пълен архивен нод. Можете да извлечете ендпойнт за всички парачейни безплатно OnFinality |
| dictionary | Низ | Низ | Препоръчва се да се предостави HTTP еднпойнт на речник с пълна верига, за да се ускори обработката - четенекак работи SubQuery речникът. |
| chaintypes | 𐄂 | {file:String} | Път към файла с типове вериги, приема.jsonили.yaml формат |
Спец. източник на данни
Дефинира данните, които ще бъдат филтрирани и извлечени, и местоположението на манипулатора на функцията за преобразуване, за да се приложи трансформацията на данни.
| Поле | v0.0.1 | v0.2.0 | Описание |
|---|---|---|---|
| name | Низ | 𐄂 | Име на източника на данни |
| kind | substrate/Runtime | substrate/Runtime, substrate/CustomDataSource | Поддържаме тип данни от среда за изпълнение на субстрата по подразбиране, като блок, събитие и външно (повикване). От v0.2.0 поддържаме данни от персонализирана среда за изпълнение, като интелигентен договор. |
| startBlock | Цяло число | Цяло число | Това променя вашия начален блок за индексиране, задайте го по-високо, за да пропуснете първоначалните блокове с по-малко данни |
| mapping | Мапинг спецификации | Мапинг спецификации | |
| filter | network-filters | 𐄂 | Филтрирайте източника на данни за изпълнение по името на спецификацията на ендпойнта на мрежата |
Мапинг спецификации
| Поле | v0.0.1 | v0.2.0 | Описание |
|---|---|---|---|
| file | Низ | 𐄂 | Път до записа за мапинг |
| handlers & filters | Манипулатори и филтри по подразбиране | Манипулатори и филтри по подразбиране, Персонализирани манипулатори и филтри | Избройте всички мапинг функции и съответните им типове манипулатори, с допълнителни филтри за мапинг. За персонализирани манипулатори за мапинг по време на изпълнение, моля, вижте Персонализирани източници на данни |
Източници на данни и мапинг
В този раздел ще говорим за времето за изпълнение на substrate по подразбиране и неговият мапинг. Ето един пример:
dataSources:
- kind: substrate/Runtime # Indicates that this is default runtime
startBlock: 1 # This changes your indexing start block, set this higher to skip initial blocks with less data
mapping:
file: dist/index.js # Entry path for this mapping
Манипулатори на мапинг и филтри
Следващата таблица обяснява филтрите, поддържани от различни манипулатори.
Вашият SubQuery проект ще бъде много по-ефективен, когато използвате само манипулатори на събития и повиквания с подходящи филтри за мапинг
| Манипулатор | Поддържан филтър |
|---|---|
| BlockHandler | specVersion |
| EventHandler | module,method |
| CallHandler | module,method ,success |
Филтрите за мапинг по време на изпълнение са изключително полезна функция, за да решите кой блок, събитие или външен елемент ще задейства мапинг манипулатор.
Само входящите данни, които отговарят на условията на филтъра, ще бъдат обработени от мапинг функциите. Мапинг филтрите не са задължителни, но са силно препоръчителни, тъй като значително намаляват количеството данни, обработвани от вашия SubQuery проект и ще подобрят ефективността на индексирането.
# Примерен филтър от callHandler
филтър:
module: balances
method: Deposit
success: true
- Филтрите за модули и методи се поддържат на всяка верига, базирана на substrate.
- Филтърът за
успехприема булева стойност и може да се използва за филтриране на външния по неговия статус на успех. - Филтърът
specVersionопределя диапазона на версията на спецификацията за блок на substrate. Следващите примери описват как да зададете диапазони на версиите.
филтър:
specVersion: [23, 24] # Индексен блок със specVersion между 23 и 24 (включително).
specVersion: [100] # Индексен блок със specVersion по-голям или равен на 100.
specVersion: [null, 23] # Индексен блок със specVersion по-малък или равен на 23.
Персонализирани вериги
Мрежова спецификация
Когато се свързвате към различен парачейн на Polkadot или дори към персонализирана верига на substrate, ще трябва да редактирате раздела за мрежови спецификации на този манифест.
genesisHash винаги трябва да бъде хешът на първия блок от персонализираната мрежа. Можете лесно да промените това, като отидете на PolkadotJS and looking for the hash on block 0 (вижте изображението по-долу).
Освен това, ще трябва да актуализирате ендпойнта. Това дефинира ендпойнта wss на блокчейна, която трябва да бъде индексирана - това трябва да е пълен архивен нод. Можете да извлечете ендпойнт за всички парачейни безплатно OnFinality
Видове вериги
Можете да индексирате данни от персонализирани вериги, като включите и типове вериги в манифеста.
Поддържаме допълнителните типове, използвани от модулите на substrate, по време на изпълнение typesAlias, typesBundle, typesChain, поддържат се и typesSpec.
В примера v0.2.0 по-долу, network.chaintypes сочат към файл, който включва всички персонализирани типове. Това е стандартен файл със спецификации на веригата, който декларира специфичните типове, поддържани от този блокчейн в .json, .yaml или .js формат.
::: code-tabs @tab v0.2.0 yml network: genesisHash: '0x91b171bb158e2d3848fa23a9f1c25182fb8e20313b2c1eb49219da7a70ce90c3' endpoint: 'ws://host.kittychain.io/public-ws' chaintypes: file: ./types.json # относителният път на файла до мястото, където се съхраняват персонализирани типове ...
За да използвате машинопис за вашия файл с типове вериги, включете го в папка src (например ./src/types.ts), стартирайте yarn build и след това посочете генерирания js файл, разположен в папка dist.
network:
chaintypes:
file: ./dist/types.js # Ще бъде генерирано след изграждане на прежда
Неща, които трябва да отбележите относно използването на файла с типове вериги с разширение .ts или .js:
- Версията на манифеста ви трябва да е v0.2.0 или по-нова.
- Само експортирането по подразбиране ще бъде включено в polkadot api при извличане на блокове.
Ето пример за файл с .ts типове вериги:
::: code-tabs @tab types.ts ts import { typesBundleDeprecated } from "moonbeam-types-bundle" export default { typesBundle: typesBundleDeprecated }; :::
Персонализирани източници на данни
Персонализираните източници на данни предоставят специфична за мрежата функционалност, която улеснява работата с данни. Те действат като междинен софтуер, който може да осигури допълнително филтриране и трансформация на данни.
Добър пример за това е поддръжката на EVM, когато имате персонализиран процесор за източник на данни за EVM означава, че можете да филтрирате на ниво EVM (напр. филтриране на договорни методи или логове) и данните се трансформират в структури, подобни на екосистемата на Ethereum, както и параметри за анализиране с ABIs.
Персонализираните източници на данни могат да се използват с нормални източници на данни.
Ето списък на поддържаните персонализирани източници на данни:
| Тип | Поддържани манипулатори | Филтри | Описание |
|---|---|---|---|
| substrate/Moonbeam | substrate/MoonbeamEvent, substrate/MoonbeamCall | Вижте филтрите под всеки манипулатор | Осигурява лесно взаимодействие с EVM транзакции и събития в мрежите на Moonbeams |
Мрежови филтри
**Мрежовите филтри се отнасят само за манифест спецификация v0.0.1. **.
Обикновено потребителят ще създаде SubQuery и ще очаква да го използва повторно както за своята тестова, така и за основната среда (напр. Polkadot и Kusama). Между мрежите е вероятно разнообразните опции да са различни (напр. начален блок на индекса). Следователно ние позволяваме на потребителите да дефинират различни подробности за всеки източник на данни, което означава, че един SubQuery проект, все още може да се използва в множество мрежи.
Потребителите могат да добавят филтър към dataSources за да решат кой източник на данни да се изпълнява във всяка мрежа.
По-долу е даден пример, който показва различни източници на данни за мрежите Polkadot и Kusama.
::: code-tabs @tab v0.0.1 yaml --- network: endpoint: 'wss://polkadot.api.onfinality.io/public-ws' #Създайте шаблон, за да избегнете излишък определения: mapping: &mymapping handlers: - handler: handleBlock kind: substrate/BlockHandler dataSources: - name: polkadotRuntime kind: substrate/Runtime filter: #По избор specName: polkadot startBlock: 1000 mapping: *mymapping #use template here - name: kusamaRuntime kind: substrate/Runtime filter: specName: kusama startBlock: 12000 mapping: *mymapping # can reuse or change
:::