Moved from GitHub dgraph/5816
Posted by martaver:
Steps to reproduce the issue (command/config used to run Dgraph).
Using slash graphql, given the schema:
type Player {
id: ID!
title: String! @search(by: [fulltext])
parent: Player
children: [Player] @hasInverse(field: parent)
}
Add a root Player with two child Players:
mutation {
addPlayer(input: [
{
title: "root",
children: [
{
title: "A"
},
{
title: "B"
}
]
}
]) {
player {
id
title
children {
id
title
}
}
}
}
Now, I wish to re-order [A,B] to [B,A]. So I use the following mutation:
mutation SetPlayerTree($id: ID!, $children: [PlayerRef]) {
updatePlayer(input: {
filter: {
id: [$id]
}
set: {
children: $children
}
}) {
player {
id
children {
id
}
}
}
}
With vars:
{
"id": "0x4e22",
"children": [{"id": "0x4e26"}, {"id": "0x4e25"}]
}
Expected behaviour and actual result.
I was hoping for the order of children to have been updated to [B,A], but instead I get [A,B]:
{
"data": {
"updatePlayer": {
"player": [
{
"id": "0x4e22",
"children": [
{
"id": "0x4e25"
},
{
"id": "0x4e26"
}
]
}
]
}
},
"extensions": {
"touched_uids": 25,
"queryCost": 1
}
}
I understand that ordering isn’t probably something that dgraph considers because it treats it edges as ‘sets’ rather than lists, but the goal here is to provide utility above and beyond a graphql API implemented with a relational or document db.
A relational db can’t implicitly preserve ordering of inputs without the select query sorting by an index column. So in this respect, dgraph provides equivalent functionality.
A document db can preserve ordering of inputs because when it keeps references to a shared object as a list, the order of elements is also saved. So in this respect, dgraph falls short.
Preserving ordering of one-to-many relationships is a tricky problem for developers to solve. In the case of dgraph and relational dbs, the approach of creating an ‘index’ field on the element entity is problematic - what if the element is a part of many different collections? Would each relation need a different index?
This is exactly the kind of problem that drove people away from relational dbs towards document dbs, and in my mind it’s the kind of problem that dgraph should be able to solve for developers ‘out of the box’.
Actually, dgraph is uniquely positioned to be able to solve this problem extremely elegantly, because the index of an element’s membership in a collection can be stored on the edge as a facet. In this way, the index information is stored in the context of the relationship and the element itself doesn’t need any ‘index fields’.
I firmly believe that this simple fix would be a massive quality of life improvement for developers and really set dgraph above other options for front-end development.
