Манифест Файл

... 2022-9-24 About 2 min

# Манифест Файл

Файлът Manifest project.yaml може да се разглежда като входящата точка на вашия проект, той дефинира повечето подробности за това как SubQuery ще индексира и трансформира данните от веригата.

Манифестът може да бъде във формат YAML или JSON. В този документ ще използваме YAML във всички примери. По-долу е даден стандартен пример за основен project.yaml.

# Мигриране от 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 (opens new window)
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
1
2
3
4
5

# Манипулатори на мапинг и филтри

Следващата таблица обяснява филтрите, поддържани от различни манипулатори.

Вашият SubQuery проект ще бъде много по-ефективен, когато използвате само манипулатори на събития и повиквания с подходящи филтри за мапинг

Манипулатор Поддържан филтър
BlockHandler specVersion
EventHandler module,method
CallHandler module,method ,success

Филтрите за мапинг по време на изпълнение са изключително полезна функция, за да решите кой блок, събитие или външен елемент ще задейства мапинг манипулатор.

Само входящите данни, които отговарят на условията на филтъра, ще бъдат обработени от мапинг функциите. Мапинг филтрите не са задължителни, но са силно препоръчителни, тъй като значително намаляват количеството данни, обработвани от вашия SubQuery проект и ще подобрят ефективността на индексирането.

# Примерен филтър от callHandler
филтър:
  module: balances
  method: Deposit
  success: true
1
2
3
4
5
  • Филтрите за модули и методи се поддържат на всяка верига, базирана на substrate.
  • Филтърът за успех приема булева стойност и може да се използва за филтриране на външния по неговия статус на успех.
  • Филтърът specVersion определя диапазона на версията на спецификацията за блок на substrate. Следващите примери описват как да зададете диапазони на версиите.
филтър:
  specVersion: [23, 24]   # Индексен блок със specVersion между 23 и 24 (включително).
  specVersion: [100]      # Индексен блок със specVersion по-голям или равен на 100.
  specVersion: [null, 23] # Индексен блок със specVersion по-малък или равен на 23.
1
2
3
4

# Персонализирани вериги

# Мрежова спецификация

Когато се свързвате към различен парачейн на Polkadot или дори към персонализирана верига на substrate, ще трябва да редактирате раздела за мрежови спецификации на този манифест.

genesisHash винаги трябва да бъде хешът на първия блок от персонализираната мрежа. Можете лесно да промените това, като отидете на PolkadotJS (opens new window) and looking for the hash on block 0 (вижте изображението по-долу).

Genesis Hash

Освен това, ще трябва да актуализирате ендпойнта. Това дефинира ендпойнта wss на блокчейна, която трябва да бъде индексирана - това трябва да е пълен архивен нод. Можете да извлечете ендпойнт за всички парачейни безплатно OnFinality (opens new window)

# Видове вериги

Можете да индексирате данни от персонализирани вериги, като включите и типове вериги в манифеста.

Поддържаме допълнителните типове, използвани от модулите на substrate, по време на изпълнение typesAlias, typesBundle, typesChain, поддържат се и typesSpec.

В примера v0.2.0 по-долу, network.chaintypes сочат към файл, който включва всички персонализирани типове. Това е стандартен файл със спецификации на веригата, който декларира специфичните типове, поддържани от този блокчейн в .json, .yaml или .js формат.

За да използвате машинопис за вашия файл с типове вериги, включете го в папка src (например ./src/types.ts), стартирайте yarn build и след това посочете генерирания js файл, разположен в папка dist.

network:
  chaintypes:
    file: ./dist/types.js # Ще бъде генерирано след изграждане на прежда
1
2
3

Неща, които трябва да отбележите относно използването на файла с типове вериги с разширение .ts или .js:

  • Версията на манифеста ви трябва да е v0.2.0 или по-нова.
  • Само експортирането по подразбиране ще бъде включено в polkadot api (opens new window) при извличане на блокове.

Ето пример за файл с .ts типове вериги:

# Персонализирани източници на данни

Персонализираните източници на данни предоставят специфична за мрежата функционалност, която улеснява работата с данни. Те действат като междинен софтуер, който може да осигури допълнително филтриране и трансформация на данни.

Добър пример за това е поддръжката на EVM, когато имате персонализиран процесор за източник на данни за EVM означава, че можете да филтрирате на ниво EVM (напр. филтриране на договорни методи или логове) и данните се трансформират в структури, подобни на екосистемата на Ethereum, както и параметри за анализиране с ABIs.

Персонализираните източници на данни могат да се използват с нормални източници на данни.

Ето списък на поддържаните персонализирани източници на данни:

Тип Поддържани манипулатори Филтри Описание
substrate/Moonbeam substrate/MoonbeamEvent, substrate/MoonbeamCall Вижте филтрите под всеки манипулатор Осигурява лесно взаимодействие с EVM транзакции и събития в мрежите на Moonbeams

# Мрежови филтри

**Мрежовите филтри се отнасят само за манифест спецификация v0.0.1. **.

Обикновено потребителят ще създаде SubQuery и ще очаква да го използва повторно както за своята тестова, така и за основната среда (напр. Polkadot и Kusama). Между мрежите е вероятно разнообразните опции да са различни (напр. начален блок на индекса). Следователно ние позволяваме на потребителите да дефинират различни подробности за всеки източник на данни, което означава, че един SubQuery проект, все още може да се използва в множество мрежи.

Потребителите могат да добавят филтър към dataSources за да решат кой източник на данни да се изпълнява във всяка мрежа.

По-долу е даден пример, който показва различни източници на данни за мрежите Polkadot и Kusama.

Last update: September 24, 2022 05:55