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

问题描述

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

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

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

解决方案

通常，当连接使用不同的参数时，游标不必相同.例如，如果我这样做了:

  {namedFriends:朋友(orderby:NAME开头:5){边缘{光标，节点{id}}}最喜欢的朋友:朋友(orderby:FAVORITE first:5){边缘{光标，节点{id}}}} 

不同的后端可能用于服务这两个连接，因为我们对于这两个排序可能有不同的后端；因此，同一个朋友的光标可能有所不同，因为它们可能需要为不同的后端编码不同的信息.

尽管如此，这会使执行突变时变得棘手:

 变异M {addFriend($ input){newFriendsEdge {{cursor，node {id}}}//这是哪个光标?}}} 

在这种情况下，突变将要从连接返回一条边，因此 field 接受与连接相同的非分页参数是很有用的.因此，在上述情况下，我们将执行以下操作:

 变异M {addFriend($ input){newNamedFriendsEdge:newFriendsEdge(orderby:NAME){{cursor，node {id}}}//namedFriends的光标}newFavoriteFriendsEdge:newFriendsEdge(orderby:FAVORITE){{cursor，node {id}}}//Cursor for favoriteFriends}}} 

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

>

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

 变异M {addFriend($ input){newFriendsEdge {{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!

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