MichelDiz
April 27, 2020, 5:46pm
4
Thanks for sharing it. I gonna answer in parts.
Take this query as an example
The main point to get the right responses from Dgraph, is to never use “var” block if you wanna see what you are doing.
upsert {
query {
q(func: eq(email, "user@company1.io")) {
v as uid
}
}
mutation {
set {
uid(v) <email> "user@company1.io" .
uid(v) <age> "28" .
}
}
}
The first time you run it you will get this answer.
{
"data": {
"code": "Success",
"message": "Done",
"queries": {
"q": []
},
"uids": {
"uid(v)": "0x4e22"
}
}
}
As you can see, the “uids” field indicates that we have created a new node and it returns us a UID in the “uid (v)” key.
If you run the same query again, it gonna return this
{
"data": {
"code": "Success",
"message": "Done",
"queries": {
"q": [
{
"uid": "0x4e22"
}
]
},
"uids": {}
}
}
As you can see, the “uids” field is empty and now we have a response in the “queries” field. This indicates that a new node was not created. “0x4e22” is the node that has the email “user@company1.io”.
For now, that’s the behavior you have to pay attention to.
See this issue to understand what happened in that context.https://github.com/dgraph-io/dgraph/issues/4048
Also, follow this
opened 06:18PM - 23 Jan 20 UTC
kind/enhancement
area/upsert
dgraph
## Experience Report
### What you wanted to do
I would like to run an Upse… rt Block query and get the response to that operation right away.
### What you actually did
Today https://github.com/dgraph-io/dgraph/pull/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 https://github.com/dgraph-io/dgraph/issues/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:
```Graphql
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>]
...
}
```
```Graphql
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
```JSON
{
"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
}
]
}
}
}
```