The Graph QL Schema

Genel Bakış

The schema for your Subgraph is in the file schema.graphql. GraphQL schemas are defined using the GraphQL interface definition language.

Varlıkları Tanımlama

Varlıkları tanımlamadan önce, verilerinizin nasıl yapılandırıldığını ve nasıl bağlantılı olduğunu düşünmek önemlidir.

• All queries will be made against the data model defined in the Subgraph schema. As a result, the design of the Subgraph schema should be informed by the queries that your application will need to perform.
• Varlıkları, olaylar veya fonksiyonlar yerine “veri içeren nesneler” olarak düşünmek faydalı olabilir.
• You 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.
• Varsayılan olarak, varlıklar değiştirilebilirdir; yani, eşlemeler halihazırda mevcut varlıkları yükleyebilir, onları modifiye edebilir ve o varlığın yeni bir sürümünü saklayabilir.
  • Mutability comes at a price, so for entity types that will never be modified, such as those containing data extracted verbatim from the chain, it is recommended to mark them as immutable with @entity(immutable: true).
  • Varlığın oluşturulduğu blok içinde değişiklikler gerçekleşirse, eşlemeler değişmez varlıkları değiştirebilir. Değişmez varlıklar çok daha hızlı yazılabilir ve sorgulanabilir olduğundan, mümkün olduğunca kullanılmaları önerilir.

İyi Bir Örnek

The following Gravatar entity is structured around a Gravatar object and is a good example of how an entity could be defined.

1type Gravatar @entity(immutable: true) {2  id: Bytes!3  owner: Bytes4  displayName: String5  imageUrl: String6  accepted: Boolean7}

Kötü Bir Örnek

The following example GravatarAccepted and GravatarDeclined entities are based around events. It is not recommended to map events or function calls to entities 1:1.

1type GravatarAccepted @entity {2  id: Bytes!3  owner: Bytes4  displayName: String5  imageUrl: String6}78type GravatarDeclined @entity {9  id: Bytes!10  owner: Bytes11  displayName: String12  imageUrl: String13}

Opsiyonel ve Zorunlu Alanlar

Entity fields can be defined as required or optional. Required fields are indicated by the ! in the schema. If the field is a scalar field, you get an error when you try to store the entity. If the field references another entity then you get this error:

1Null value resolved for non-null field 'name'

Each entity must have an id field, which must be of type Bytes! or String!. It is generally recommended to use Bytes!, unless the id contains human-readable text, since entities with Bytes! id’s will be faster to write and query as those with a String! id. The id field serves as the primary key, and needs to be unique among all entities of the same type. For historical reasons, the type ID! is also accepted and is a synonym for String!.

For some entity types the id for Bytes! is constructed from the id’s of two other entities; that is possible using concat, e.g., let id = left.id.concat(right.id) to form the id from the id’s of left and right. Similarly, to construct an id from the id of an existing entity and a counter count, let id = left.id.concatI32(count) can be used. The concatenation is guaranteed to produce unique id’s as long as the length of left is the same for all such entities, for example, because left.id is an Address.

Gömülü Skaler(Scalar) Türler

GraphQL’in Desteklediği Skalerler

GraphQL API’sinde desteklenen skalarlardan bazıları şunlardır:

Numaralandırmalar

Ayrıca bir şema içinde numaralandırmalar da oluşturabilirsiniz. Numaralandırmalar aşağıdaki sözdizimine sahiptir:

1enum TokenStatus {2  OriginalOwner3  SecondOwner4  ThirdOwner5}

Once the enum is defined in the schema, you can use the string representation of the enum value to set an enum field on an entity. For example, you can set the tokenStatus to SecondOwner by first defining your entity and subsequently setting the field with entity.tokenStatus = "SecondOwner". The example below demonstrates what the Token entity would look like with an enum field:

More detail on writing enums can be found in the GraphQL documentation⁠.

Varlık İlişkileri

Bir varlık, şemanızdaki bir veya daha fazla başka varlıkla ilişkili olabilir. Bu ilişkiler, sorgularınızda çaprazlanabilir. Graph’taki ilişkiler tek yönlüdür. İki yönlü ilişkileri simüle etmek, ilişkinin herhangi biri “son” üzerinde tek yönlü bir ilişki tanımlayarak mümkündür.

İlişkiler, belirtilen türün başka bir varlığın türü olması dışında, diğer tüm alanlarda olduğu gibi varlıklar üzerinde tanımlanır.

Bire Bir İlişkiler

Define a Transaction entity type with an optional one-to-one relationship with a TransactionReceipt entity type:

1type Transaction @entity(immutable: true) {2  id: Bytes!3  transactionReceipt: TransactionReceipt4}56type TransactionReceipt @entity(immutable: true) {7  id: Bytes!8  transaction: Transaction9}

Birden Çoğa İlişkiler

Define a TokenBalance entity type with a required one-to-many relationship with a Token entity type:

1type Token @entity(immutable: true) {2  id: Bytes!3}45type TokenBalance @entity {6  id: Bytes!7  amount: Int!8  token: Token!9}

Tersine Aramalar

Reverse lookups can be defined on an entity through the @derivedFrom field. This creates a virtual field on the entity that may be queried but cannot be set manually through the mappings API. Rather, it is derived from the relationship defined on the other entity. For such relationships, it rarely makes sense to store both sides of the relationship, and both indexing and query performance will be better when only one side is stored and the other is derived.

For one-to-many relationships, the relationship should always be stored on the ‘one’ side, and the ‘many’ side should always be derived. Storing the relationship this way, rather than storing an array of entities on the ‘many’ side, will result in dramatically better performance for both indexing and querying the Subgraph. In general, storing arrays of entities should be avoided as much as is practical.

Örnek

We can make the balances for a token accessible from the token by deriving a tokenBalances field:

1type Token @entity(immutable: true) {2  id: Bytes!3  tokenBalances: [TokenBalance!]! @derivedFrom(field: "token")4}56type TokenBalance @entity {7  id: Bytes!8  amount: Int!9  token: Token!10}

Here is an example of how to write a mapping for a Subgraph with reverse lookups:

1let token = new Token(event.address) // Create Token2token.save() // tokenBalances is derived automatically34let tokenBalance = new TokenBalance(event.address)5tokenBalance.amount = BigInt.fromI32(0)6tokenBalance.token = token.id // Reference stored here7tokenBalance.save()

Çoktan Çoğa İlişkiler

Kullanıcıların her birinin birden çok kuruluşa mensup olabileceği gibi çoktan çoğa ilişkilerde, ilişkiyi modellemenin en basit fakat pek verimli olmayan yolu, ilişkide yer alan iki varlıkta da bir dizi olarak saklamaktır. İlişki simetrik ise, ilişkinin yalnızca bir tarafının saklanması gerekir ve diğer taraf türetilebilir.

Örnek

Define a reverse lookup from a User entity type to an Organization entity type. In the example below, this is achieved by looking up the members attribute from within the Organization entity. In queries, the organizations field on User will be resolved by finding all Organization entities that include the user’s ID.

1type Organization @entity {2  id: Bytes!3  name: String!4  members: [User!]!5}67type User @entity {8  id: Bytes!9  name: String!10  organizations: [Organization!]! @derivedFrom(field: "members")11}

A more performant way to store this relationship is through a mapping table that has one entry for each User / Organization pair with a schema like

1type Organization @entity {2  id: Bytes!3  name: String!4  members: [UserOrganization!]! @derivedFrom(field: "organization")5}67type User @entity {8  id: Bytes!9  name: String!10  organizations: [UserOrganization!] @derivedFrom(field: "user")11}1213type UserOrganization @entity {14  id: Bytes! # Set to `user.id.concat(organization.id)`15  user: User!16  organization: Organization!17}

Bu yaklaşım, örneğin kullanıcılar için kuruluşları almak için sorguların ek bir seviyeye inmesini gerektirir:

1query usersWithOrganizations {2  users {3    organizations {4      # this is a UserOrganization entity5      organization {6        name7      }8    }9  }10}

This more elaborate way of storing many-to-many relationships will result in less data stored for the Subgraph, and therefore to a Subgraph that is often dramatically faster to index and to query.

Şemaya notlar/yorumlar ekleme

As per GraphQL spec, comments can be added above schema entity attributes using the hash symbol #. This is illustrated in the example below:

1type MyFirstEntity @entity {2  # # varlığın benzersiz tanımlayıcısı ve birincil anahtarı3  id: Bytes!4  address: Bytes!5}

Tam Metinde Arama Alanlarını Tanımlama

Tam metinde arama sorguları, metin arama girdisine dayanarak varlıkları filtreler ve sıralar. Tam metin sorguları, sorgu metni girişini indekslenmiş metin verileriyle karşılaştırmadan önce köklere işleyerek benzer kelimeler için eşleşmeler döndürebilir.

Tam metin sorgusu tanımı, sorgu adı, metin alanlarını işlemek için kullanılan dil sözlüğü, sonuçları sıralamak için kullanılan sıralama algoritması ve aramaya dahil edilen alanları içerir. Her tam metin sorgusu birden fazla alana yayılabilir, ancak dahil edilen tüm alanlar tek bir varlık türünden olmalıdır.

To add a fulltext query, include a _Schema_ type with a fulltext directive in the GraphQL schema.

1type _Schema_2  @fulltext(3    name: "bandSearch"4    language: en5    algorithm: rank6    include: [{ entity: "Band", fields: [{ name: "name" }, { name: "description" }, { name: "bio" }] }]7  )89type Band @entity {10  id: Bytes!11  name: String!12  description: String!13  bio: String14  wallet: Address15  labels: [Label!]!16  discography: [Album!]!17  members: [Musician!]!18}

The example bandSearch field can be used in queries to filter Band entities based on the text documents in the name, description, and bio fields. Jump to GraphQL API - Queries for a description of the fulltext search API and more example usage.

1query {2  bandSearch(text: "breaks & electro & detroit") {3    id4    name5    description6    wallet7  }8}

Desteklenen diller

Farklı bir dil seçmek, tam metin arama API’sı üzerinde bazen az olsa da kesin bir etkiye sahip olacaktır. Tam metin sorgu alanı tarafından kapsanan alanlar, seçilen dile bağlı olarak incelenir, bu nedenle analiz ve arama sorguları tarafından üretilen sözlükbirimleri dilden dile değişir. Örneğin: desteklenen Türkçe sözlük kullanıldığında “token” kelimesi “toke” olarak kök alınırken, elbette İngilizce sözlük “token” olarak kök alacaktır.

Desteklenen dil sözlükleri:

Algoritmaları Sıralama

Sonuçları sıralamak için desteklenen algoritmalar: