Support return response after the Upsert Block done. (Like GraphQL does)

[MichelDiz]

Experience Report

What you wanted to do

I would like to run an Upsert Block query and get the response to that operation right away.

What you actually did

Today #4210 covers a state before the mutation. However, this #4210 feature does not seem to be useful except in cases for making some kind of comparisons.

Why that wasn't great, with examples

Following the same line of reasoning as #4048 obtaining a response after the execution of Upsert Query is essential for the developer to be aware of what is being performed in the procedure.

Any external references to support your case

GraphQL is an external example of this feature. GraphQL mutations can return (or not, it is optional) a new query with this mutation performed in mind.

Example

The result of the "Return Query" block must return values after the upsert query is executed. That is, return the result of the operation.

Format:

upsert {
  query <query block>
  [fragment <fragment block>]
  mutation <mutation block 1>
 [mutation <mutation block 2>]
  return query <return query block>
 [return query <return query block 2>]
  ...
}

upsert {
  query {
    USER as var(func: eq(name, "abc")) {
    found as count(uid)
   }
  }
  mutation @if(eq(len(u), 0)) {
    set {
      uid(USER) <name> "abc" .
      uid(USER) <dgraph.type> "File" .
    }
  }
  return query {
  # The user can return as many blocks he needs.
  # This would be optional, If the user does not type "return query", then will return only the information we return todays.

   #This first block is the one that will return the updated data
    me(func: uid(USER)) {
      uid
      expand(_all_)
    }

    #This is a custom block - Everything here are just examples and would be optional.
    infoMe() { 
      mutation : (len(USER), 0) #This would return TRUE/FALSE if we support len() in the query body - it is just an idea
      total_sum as sum: sum(val(found))
      mutation2 : math(total_sum == 0 ) # This actually works in queries today. It will return TRUE.
    }

  }
}

Desired Result

{
  "data": {
    "code": "Success",
    "message": "Done",
    "queries": {
      "var": []
    },
    "uids": {},
    "return": {
      "me": [
        {
          "name": "test",
          "email": "user22@company1.io",
          "age": 21
        }
      ],
      "infoMe": [
        {
          "mutation": true,
          "total_sum": 1,
          "_mutation_": true
        }
      ]
    }
  }
}

[mangalaman93]

This would just be same as running the query after executing the mutation. That problem in returning a response after mutation is that the mutation may or may not have committed yet.

[MichelDiz]

But you are doing two transactions to do it. The commit wouldn't be a problem. Just return the return query after the commit. The user can wait for it in this case, if he doesn't wanna do more round trips is acceptable to wait.

Cypher and other langs have this built-in. In a single transaction, they can do several operations and return only what is specified in the RETURN func. And they also have to wait for the commit.

We can add a constraint that this kind of query just can be done if you are mutating with commitnow. If this is necessary.

[rendawudi]

so how can I get only updated uids or other custom attrs from upsert?

[MichelDiz]

In the current scenario is by doing a new query.

[rendawudi]

if upsert has a complex queries and uses client do this upsert in conditional, what can I do in a new query?