GraphQL should allow updates of multiple relational levels.

[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)
}

Create a tree of Players, with parent/children edges. Let's 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 have a UI component in the front-end that can manipulate the tree, and I want to move the Player B to be a child of Player A. It restructured the tree, and gives me a new hierarchy, which I want to push to dgraph.

mutation SetPlayerTree($id: ID!, $children: [PlayerRef]) {
    updatePlayer(input: {
        filter: {
            id: [$id]
        }
        set: {
            children: $children
        }
    }) {
        player {
        id
        children {
            id
            children {
                id
            }
        }
    }
    }
}

With vars, where B has now been moved to be a child of A (replace the ids with whatever you got from your last query):

{
  "id": "0x4e22",
  "children": [{"id": "0x4e25", "children": [{"id": "0x4e26", "children": []}]}]
}

Expected behaviour and actual result.

I would expect the response to return the hierarchy root -> A -> B, however it returns root -> [A, B]:

{
  "data": {
    "updatePlayer": {
      "player": [
        {
          "id": "0x4e22",
          "children": [
            {
              "id": "0x4e25"
            },
            {
              "id": "0x4e26"
            }
          ]
        }
      ]
    }
  },
  "extensions": {
    "touched_uids": 17,
    "queryCost": 1
  }
}

[arijitAD]

In the case of mutation, we update the Uids up to one level. But If Uid is not provided then we perform add mutation at all levels.
Hence, in this update, the nested part will be ignored.

{
  "id": "0x4e22",
  "children": [{"id": "0x4e25", "children": [{"id": "0x4e26", "children": []}]}]
}

Actual update.

{
  "id": "0x4e22",
  "children": [{"id": "0x4e25"}]
}

But this will work fine.

{
  "id": "0x4e22",
  "children": [{"id": "0x4e25", "children": [{"title": "C", "children": []}]}]
}

The documentation isn't clear on this. We will update it.
In order to achieve what you are doing, you need to perform the update on Uid of A(0x4e25) and since you are already using @hasinverse it will delete the link between root and B, and B will be added as children of A.

{
  "id": "0x4e25",
  "children": [{"id": "0x4e26"}]
}

[martaver]

Okay, I understand, that makes sense so far. I've actually implemented this the other way around, by setting 'parent' on the child node, and dgraph handles that nicely.

I would like to advocate that dgraph should accept changing relationships for more than one level, then. This would be more intuitive, because the add operation also works at multiple levels.

A use case for this is (in our case) where we have a tree editor, where the user can (locally) make a series of structural changes to a taxonomy. The content of each node stays the same but they can drag existing nodes around. Once the user selects save, the component submits the resulting tree structure in JSON format. Keep in mind that in this use case we are talking purely about updating existing nodes.

With dgraph's current updateXXX resolver, there are two APIs for mutations set and remove. In my case, I need to compare the old tree structure to the new structure, walking each node to create a sequence of diffs - additionals and removals. Then I have to match them by their UIDs to validate that I have detected all the moves in the tree. Each of these, then I send to dgraph as an update to the node's parent. After each query is done, the tree is updated.

I mention a similar scenario in my other post too: #5816 as an argument for why the updateXXX resolvers should actually have three APIs set, add and remove.

In an ideal world, I would be able to provide the desired structure of any depth and have dgraph update all relations, e.g. for original mutation input:

{
  "id": "0x4e22",
  "children": [{"id": "0x4e25", "children": [{"id": "0x4e26", "children": []}]}]
}

Having to break up such updates into a sequence of operations has a few problems:

1. It breaks transactionality and concurrency.
2. Using a front-end state management solution like Apollo Client means that each query forces a UI update, unless I write custom logic to handle mutations to the local cache optimistically.
3. It forces the front-end to incorporate logic about HOW a request is to be achieved - which is something that should be kept the responsibility of a back-end.

From this perspective, Slash GraphQL is more of a hinderance than a help. For example, why wouldn't I just implement my own Apollo Server and handle these special cases there, probably leveraging the more powerful syntax of GraphQL+/-?

Except, these aren't really special cases, we're talking about everyday problems in front-end development.

To this end, I'm going to rename this issue as a proposal to allow for multi-level updates.

[arijitAD]

Multiple level updates will solve the above use cases you mentioned. You can still use Dgraph's transaction to achieve the same, and coming to Slash GraphQL, there is a proposal to expose GraphQL+/- as well so that you will be able to use the more powerful syntax. We would consider including multiple level updates in the upcoming release based on user interests.

[martaver]

How can I use dgraph's transaction via the pure graphql endpoint?

[minhaj-shakeel]

Github issues have been deprecated.
This issue has been moved to discuss. You can follow the conversation there and also subscribe to updates by changing your notification preferences.