连接中的不透明游标是否应该在不同的字段参数中保持稳定? [英] Should the opaque cursors in connections be stable across different field args?

问题描述

RANGE_ADD 突变需要 edgeName 以便它可以将新边插入客户端连接.作为查询的一部分，它还包括 cursor.

问题是服务器无法知道客户端在生成边缘响应时可能将哪些参数应用于连接.

这是否意味着 cursor 应该是稳定的?

解决方案

一般来说，当连接使用不同的参数时，游标不需要相同.例如，如果我这样做了:

<代码>{namedFriends: 朋友(orderby:NAME first:5) {边 { 光标，节点 { id } }}最喜欢的朋友:朋友(orderby:最喜欢的第一个:5){边 { 光标，节点 { id } }}}

可能使用不同的后端来为这两个连接提供服务，因为我们可能有两个排序的不同后端；因此，同一个朋友的游标可能会有所不同，因为他们可能需要为不同的后端编码不同的信息.

不过，这使得执行突变时变得棘手:

突变 M {addFriend($input) {新朋友边缘{{ cursor, node { id } }//这是哪个光标?}}}

在这种情况下，变异将从连接返回一个边，字段接受与连接相同的非分页参数是很有用的.所以在上面的例子中，我们会这样做:

突变 M {addFriend($input) {newNamedFriendsEdge: newFriendsEdge(orderby:NAME) {{ cursor, node { id } }//namedFriends 的光标}newFavoriteFriendsEdge: newFriendsEdge(orderby:FAVORITE) {{ cursor, node { id } }//最喜欢的朋友的光标}}}

理想情况下，newFriendsEdge(orderby:FAVORITE) 和 favoriteFriends:friends(orderby:FAVORITE first:5) 的实现共享通用代码来生成游标.>

请注意，虽然游标不需要相同，但如果它们相同就可以了，作为服务器的实现细节.通常，光标只是节点的 ID，这是发生这种情况的常见方式.在实践中，在这些情况下，如果连接上的参数不影响光标，我们将从突变的边缘字段中省略它；所以如果 orderby 不影响光标，那么:

突变 M {addFriend($input) {新朋友边缘{{ cursor, node { id } }//newFriendsEdge 上不存在 orderby，因此该游标必须同时适用于两者.}}}

这是我们突变中的常见模式.如果您遇到任何问题，请告诉我；在开发返回边缘的模式时，我们考虑了参数更改游标"的情况，以确保有可能的解决方案(这是我们提出有关边缘字段想法的参数时)，但它没有在实践中出现了这么多，所以如果你遇到棘手的问题，一定要告诉我，我们可以而且应该重新审视这些假设/要求！

The RANGE_ADD mutation requires an edgeName so that it can insert the new edge into the client side connection. As part of its query, it also includes the cursor.

The issue is that the server has no way of knowing which args the client might be applying to a connection when it's generating the edge response.

Does this mean that the cursor should be stable?

解决方案

In general, cursors are not required to be the same when connections are used with different arguments. For example, if I did:

{
  namedFriends: friends(orderby:NAME first:5) {
    edges { cursor, node { id } }
  }
  favoriteFriends: friends(orderby:FAVORITE first:5) {
    edges { cursor, node { id } }
  }
}

Different backends might be use to server those two connections, since we might have different backends for the two orderings; because of that, the cursors might be different for the same friend, because they might need to encode different information for the different backends.

This makes it tricky when performing a mutation, though:

mutation M {
  addFriend($input) {
    newFriendsEdge {
      { cursor, node { id } } // Which cursor is this?
    }
  }
}

In cases like this, where the mutation is going to return an edge from a connection, it's useful for the field to accept the same non-pagination arguments that the connection does. So in the above case, we would do:

mutation M {
  addFriend($input) {
    newNamedFriendsEdge: newFriendsEdge(orderby:NAME) {
      { cursor, node { id } } // Cursor for namedFriends
    }
    newFavoriteFriendsEdge: newFriendsEdge(orderby:FAVORITE) {
      { cursor, node { id } } // Cursor for favoriteFriends
    }
  }
}

And ideally, the implementation for newFriendsEdge(orderby:FAVORITE) and favoriteFriends: friends(orderby:FAVORITE first:5) share common code to generate cursors.

Note that while the cursors are not required to be the same, it's fine if they are, as an implementation detail of the server. Often, the cursor is just the ID of the node, which is a common way for this to happen. In practice, in these situations, if a argument on the connections doesn't affect the cursor, we would omit it from the mutation's edge field; so if orderby didn't affect the cursor, then:

mutation M {
  addFriend($input) {
    newFriendsEdge {
      { cursor, node { id } } // orderby didn't exist on newFriendsEdge, so this cursor must apply to both.
    }
  }
}

This is the common pattern in our mutations. Let me know if you run into any issues; we thought through the "arguments change cursors" case when developing the pattern of returning edges on mutations to make sure there was a possible solution to it (which is when we came up with the arguments on edge fields idea), but it hasn't come up in practice all that much, so if you run into trickiness definitely let me know, and we can and should revisit these assumptions / requirements!

这篇关于连接中的不透明游标是否应该在不同的字段参数中保持稳定?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！