graphprotocol / graphprotocol/graph-node
Stricter subgraph schema validation
まだ誰も着手していません。
- 主要言語
- Rust
- スター
- 3.2k
- フォーク
- 1.1k
- 平均マージ
- 4日 1時間
- マージ済み PR(30日)
- 1
説明
Do you want to request a feature or report a bug?
Bug
What is the current behavior?
We currently allow a lot of names in schemas that either cause problems or that we want to deliberately forbid in order to give us a reserved namespace. Examples are:
-
Entity fields called
setandunset. AssemblyScript apparently allows things likeentity.set = "foo"which will replace the
set(key: string, value: Value)method in theEntitybase class with a string, which breaks all later attempts to assign fields in the same handler. -
Entity types and fields with a leading underscore (we have already introduced the special
_Schema_type and we want to move towards reserving names starting with underscores for Graph features.
If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem.
Create a subgraph with a schema like this:
type Set @entity {
id: ID!
}
type SetCreation @entity {
id: ID!
set: Set!
name: String!
}
then write a handler that does the following:
let creation = new SetCreation("foo")
creation.set = "bar"
creation.name = "baz"
this will fail to compile.
What is the expected behavior?
We should catch problematic names at deploy (or even at codegen/build time) in graph-cli and graph-node.
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
調査の方向性
issue では graph-cli と graph-node を検証のエントリーポイントとして挙げています。まず、deploy またはコード生成中に subgraph スキーマがどこでチェックされるのかを追跡してください。提供されたスキーマと handler を再現し、そのうえで、set、unset などの予約名、および先頭にアンダースコアが付いた entity 名や field 名が、deploy または build の前に拒否されることを確認してください。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- graphql, rust
- 領域
- backend-api-design, tooling
- issue の種類
- バグ
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 活発さ
- 停滞
- 明瞭さ
- おおむね明確
- 初心者へのやさしさ
- 35/100