4

ミューテーションは、データを操作するためのクエリです。もしそうなら、私root queryとroot mutation木は似ているはずですよね？どちらもネストされたフィールド (ネストされたミューテーション) を許可する必要があります。私はこれで（を使用して）遊んでいましたがexpress-graphql、動作します。

例：

// PUT /projects/:project_id/products/:id
mutation {
  findProject(id: 1) { // make sure that project exists and we can access it before mutating data
    updateProduct(id: 1, name: "Foo") { // the resolve function receives a valid `project` as the first argument
      id
    }
  } 
}

これは有効な例ですか？ミューテーションはこのように入れ子にするべきですか? いいえの場合、ネストされたリソースをどのように処理すればよいですか? ネストされたリソースを変更する実際の例は見つかりません。すべての例は、最初のレベル (ルート ミューテーションのフィールド) でのみミューテーションを定義します。

4

1 に答える 1

0

製品には一意の ID があるため、識別に必要なのはそれだけです。

mutation {
  updateProduct(id: 1, name: "Foo") {
    id
  }
}

ユーザーが製品を変更する権限を持っていることを確認するには、製品のプロジェクトを確認する必要があります。とにかく、おそらく集中型の承認が必要です。

resolve({ id }, { user }) {
  authorize(user, 'project', Product.find(id).project) // or whatever

  ... // update
}

古い答え:

これは確かに有効な例です。

ネストされたオブジェクト ミューテーションの例がないのは、製品がプロジェクトにリンクされている場合でも、ほとんどの場合は一意の ID を持っているためである可能性があると思います。そのため、プロジェクトがなくても製品を見つけることができます。 ID。

別の方法として、プロジェクト ID を の引数として含めることもできますupdateProduct。

mutation {
  updateProduct(projectId: 1, id: 1, name: "Foo") {
    id
  }
}

しかし、あなたの解決策は私には良いようです。

注意として、ミューテーションは実際にはクエリとまったく同じです。唯一の違いは、resolve関数には通常、一部のデータの変更などの永続的な変更が含まれていることです。それでも、ミューテーションはクエリと同じように動作します。つまり、引数を検証し、解決関数を呼び出し、宣言された型のデータを返します。

一部のデータが変更されることを明示するために、そのようなメソッドを (クエリではなく) ミューテーションとして宣言しますが、より重要な理由もあります: データを変更する順序は重要です。1 つのリクエストで複数のミューテーションを宣言すると、executor はそれらを順番に実行して一貫性を維持します (ただし、これは分散書き込みを解決しようとするものではありません。これはまったく別の問題です)。

于 2015-12-09T18:56:22.010 に答える