2017-01-06 6 views
1

graphene-django/GraphQLで実験を始めたばかりで、graphene-djangoのリレーライブラリについてはかなり混乱しています。クックブックのサンプル(自分のモデルで実装する)を実行し、テストクエリーを実行した後、POSTでは、エッジとノードを持つ奇妙なネストされたオブジェクトにクエリが変換されます。これらは何ですか?彼らは何をしていますか?Graphene-Django:接続、エッジ、ノードのコンセプト

+0

私はRelayにも慣れています。これは標準的な設定です。この説明はhttps:// facebookでチェックしてください。github.io/relay/graphql/connections.htm – t1m0

+0

この質問が出てきたのは、フィルタリングのリレー依存関係がなくても、私たちのアプリケーション内でgraphene-djanoを使いたかったからです。私はここでリレーを使わずにフィルタリングを追加するテクニックを見つけることができました[リンク](https://github.com/graphql-python/graphene/issues/215) –

+0

私はあなたが何を意味するかを見ます。あなたのリンクに書かれているように、リレーの規則を守ることの利点は、グラフェンがあなたにページングのためのあらかじめ構築されたセットアップを与えることです。 「pageInfo { hasNextPage hasPreviousPage startCursor endCursor }」というGraphQLクエリは自動的に動作します。 – t1m0

答えて

0
{ 
    companies { 
    edges { 
     node { 
     id 
    } 
    } 
    } 
} 

ノード

NodeFacebook Relay specs(GraphQLない仕様)の一部であることを言及する価値があるかもしれません。しかし、ほとんどのフレームワーク(Grapheneを含む)はRelayとGraphQLの密接な関連のためにこの仕様を実装しています。

本質的にNodeは、オブジェクトのグローバルに一意な識別子を意味するIDフィールドのみを実装するインターフェイスです。 IDは不透明に設計されています(一般的な規則はbase64('type:id')です)。アプリケーションはこの実装の詳細に頼るべきではありません。

Nodeがルートクエリの一部として公開されています。アプリケーションは、便利な方法で、既知のIDのエンティティをクエリできます。フェッチされていないフィールドをフェッチする。

{ 
    node(id: ID!) { 
    ... on User { 
     id 
     userId 
     name 
    } 
    ... on Company { 
     id 
     companyId 
     owner: { 
     userId 
     name 
     } 
    } 
    ... 
    } 
} 

これは、あなたが(例えばmessage(messageId)またはuser(userId))を公開するすべてのモデルのためのクエリ点を定義する必要がないの利便性を提供します。これはまた、例えば

{ 
    user { 
    friends { 
     pages { 
     name 
     } 
    } 
    } 
} 

// vs 

{ 
    node(id) { 
    ... on Page { 
     name 
    } 
    } 
} 

接続Node同様

、あなたがオブジェクトの経路を通って横断することなく、オブジェクトを照会することができ、Connectionも主流の採用への道を作ったRelay specsの一部です。

edgesのコンセプトは一見したように余分に見えますが、使いにくいユースケースを解決します。通常、データベースに結合テーブルを実装して、「友人」のような多対多の関係を公開する必要性を考慮してください。

+---------+   +------------+ 
| users |   | friends | 
+---------+   +------------+ 
| user_id | <------ | left_id | 
| .... | \--- | right_id | 
+---------+   | created_at | 
        +------------+ 

エッジオブジェクト内friends.created_atを露光することによって「[ここで日付]以降の友達」を表示するために今容易です。

{ 
    user { 
    friends { 
     edges { 
     created_at <--- 
     user { 
      id 
      userId 
      name 
     } 
     } 
    } 
    } 
} 

edges本質的nodesとの間の関係を定義します。

+------+------+------------+--------+ 
| A_id | B_id | Created_at | Status | 
+------+------+------------+--------+ 

はそれが正しいような表現edge M2Mため言うことです:AtableBtableマスト間

0

M2M関係は、少なくとも2つの外部キーを持たなければならない第3リンク(結合)テーブルABLinkによって実現されますデータベースのリンク(結合)テーブル? それでは、それは次のようになります:

{ 
    Atable { 
    ABLink { 
     edges { 
     Created_at 
     Status 
     Btable { 
      Btable_id 
      Btable_column_1 
      Btable_column_2 
      ... 
     } 
     } 
    } 
    } 
} 
関連する問題