[英]Graphene-Django: Concepts of Connections, Edges, and Nodes
I just started experimenting with graphene-django/GraphQL and am pretty confused about the relay library that has been brought in for graphene-django. 我刚刚开始尝试使用graphene-django / GraphQL,并且对于为石墨烯-django引入的继电器库非常困惑。 After running through the cookbook example (implementing it with my own models) and running a test query, upon POST the query gets transformed to a strangely nested object with edges and nodes.
在运行cookbook示例(使用我自己的模型实现它)并运行测试查询之后,在POST时,查询将转换为具有边和节点的奇怪嵌套对象。 What are these and what are they doing?
这些是什么,他们在做什么?
{
companies {
edges {
node {
id
}
}
}
}
It may be worth mentioning that Node
is part of the Facebook Relay specs (not GraphQL specs). 值得一提的是,
Node
是Facebook Relay规范 (不是GraphQL规范)的一部分。 However, most framework (Graphene included) implement this spec due to the close association between Relay and GraphQL. 但是,由于Relay和GraphQL之间的密切关联,大多数框架(包括Graphene)都实现了此规范。
Essentially Node
is an interface that implements just an ID
field, which is meant to be an globally unique identifier for an object. Essentially
Node
是一个只实现ID
字段的接口,它是一个对象的全局唯一标识符。 ID
s are designed to be opaque (typical convention is to base64('type:id')
), applications should not attempt to rely on this implementation detail. ID
被设计为不透明(典型的约定是base64('type:id')
),应用程序不应该尝试依赖此实现细节。
Node
is exposed as part of the root Query, where applications can query for entities with known ID
in a convenient way, eg refetching, fetching fields that have not been fetched. Node
作为根查询的一部分公开,其中应用程序可以方便的方式查询具有已知ID
实体,例如,重新获取,获取尚未获取的字段。
{
node(id: ID!) {
... on User {
id
userId
name
}
... on Company {
id
companyId
owner: {
userId
name
}
}
...
}
}
This provides the convenience of not having to define query point for every model you expose (eg message(messageId)
or user(userId)
). 这提供了不具有定义查询点为每一个模型你暴露(例如方便
message(messageId)
或user(userId)
This also allows you to query for the object without transversing through an object path, example 这也允许您在不遍历对象路径的情况下查询对象,例如
{
user {
friends {
pages {
name
}
}
}
}
// vs
{
node(id) {
... on Page {
name
}
}
}
Like Node
, Connection
is also part of the Relay specs that made its way to mainstream adoption. 与
Node
一样, Connection
也是Relay规范的一部分,这些规范已经成为主流采用的方式。
At first glance, the concept of edges
seems superfluous but it does solve some tricky use case. 乍一看,
edges
的概念似乎是多余的,但它确实解决了一些棘手的用例。 Consider the need to expose a many-to-many relationship like 'friends', typically implemented in a database with a join table. 考虑需要公开像“朋友”这样的多对多关系,通常在带有连接表的数据库中实现。
+---------+ +------------+
| users | | friends |
+---------+ +------------+
| user_id | <------ | left_id |
| .... | \--- | right_id |
+---------+ | created_at |
+------------+
It is now easy to display "Friends since [date here]" by exposing friends.created_at
in the edge object. 现在通过在edge对象中公开
friends.created_at
,可以很容易地显示“自[date here]以来的friends.created_at
”。
{
user {
friends {
edges {
created_at <---
user {
id
userId
name
}
}
}
}
}
edges
essentially defines the relationship between nodes
. edges
实质上定义了nodes
之间的关系。
M2M relationship between Atable
and Btable
must to be implemented by third link (join) table ABLink
, which must have at least two foreign keys: Atable
和Btable
之间的M2M关系必须由第三个链接(join)表ABLink
,该表必须至少有两个外键:
+------+------+------------+--------+
| A_id | B_id | Created_at | Status |
+------+------+------------+--------+
Is it right to say for m2m that edge
represent such link (join) table in database? 对m2m说
edge
代表数据库中的这种链接(连接)表是否正确? So then query for that would be: 那么查询就是:
{
Atable {
ABLink {
edges {
Created_at
Status
Btable {
Btable_id
Btable_column_1
Btable_column_2
...
}
}
}
}
}
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.