节点

Question

我刚刚开始尝试使用石墨烯-django / GraphQL，并且对于为石墨烯-django引入的继电器库非常困惑。在运行cookbook示例（使用我自己的模型实现它）并运行测试查询之后，在POST时，查询将转换为具有边和节点的奇怪嵌套对象。这些是什么，他们在做什么？

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

Answer 1

节点

值得一提的是Node是Facebook Relay specs（不是GraphQL规范）的一部分。但是，由于Relay和GraphQL之间的密切关联，大多数框架（包括Graphene）都实现了这个规范。

基本上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之间的关系。

Answer 2

Atable和Btable之间的M2M关系必须由第三个链接（加入）表ABLink实现，该表必须至少有两个外键：

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

对于m2m来说，edge代表数据库中的这种链接（连接）表是否正确？那么查询就是：

{
  Atable {
    ABLink {
      edges {
        Created_at
        Status
        Btable {
          Btable_id
          Btable_column_1
          Btable_column_2
          ...
        }
      }
    }
  }
}

Graphene-Django：连接，边缘和节点的概念

2 个答案:

节点

连接