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, "[email protected] ")) {
v as uid
}
}
mutation {
set {
uid(v) <email> "[email protected] " .
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 “[email protected]
For now, that’s the behavior you have to pay attention to.
See this issue to understand what happened in that context.
opened 08:13PM - 23 Sep 19 UTC
closed 06:20PM - 23 Jan 20 UTC
area/upsert
kind/enhancement
priority/P2
status/needs-specs
## Experience Report
### What you wanted to do
I would like to execute Ups… erts transactions and have a logical response from what is happening. Sometimes we send a transaction that does not return contextual information about the transaction itself. We only have some information when the transaction creates a new object in the DB. But it's not human-friendly.
### Why that wasn't great, with examples
For example, if I want to bind two entities in one Upsert. I will get a "Success" + "Done" code and an empty "uids" field. This information does not help me debug what is happening. I know there was writing because I can check directly by making a new query.
```js
{
data: { code: 'Success', message: 'Done', uids: {} },
extensions: {
server_latency: { parsing_ns: 73769, processing_ns: 5960909 },
txn: { start_ts: 653, commit_ts: 654 }
}
}
```
What we need is something like (That would be just a sketching idea, certainly should follow established standards/patterns):
If the user sends an upsert and there was a writing in Dgraph.
```js
{
data: { code: 'Success', recorded: 'true', message: 'Done', uids: { 'uid(USER)': '0x5092d' } }
//(...)
}
```
If the user sends an upsert and there was no writing in Dgraph.
```js
{
data: { code: 'Success', recorded: 'false', message: 'Done', uids: {} }
//(...)
}
```
Now let's say I use "cond()" on a mutation. I have no information about the context of this condition when performed. Whether it wrote it or not. Let's say my cond is "@if (NOT eq (len (USER), 1))" - ie it will only write if the value is zero. This happens without the dev/user being aware of what is happening.
In the Cond hypothesis, it would be ideal to return values confirming or not the writing.
If the user sends an upsert with a condition (`@if(NOT eq(len(USER), 1))`) and there was a writing in Dgraph.
>In this case, we assume that the result of the condition was "found no user". Since the condition proposal matches the result then the answer is "cond: 'true'".
```js
{
data: { code: 'Success', recorded: 'true', message: 'Done', uids: { 'uid(USER)': '0x5092d' }, cond: 'true' }
//(...)
}
```
>In the case of multiple conditions (as it would be in the case of multiple mutations), then each new condition would have to have a field of its own. e.g. `cond0: 'true', cond1: 'false', cond2: 'true',`
>Maybe
>```
>cond: {0: 'true', 1: 'false', 2: 'true'},
>```
>named mutations
>```
>cond: { "userMutation": 'true', "schoolEnroll": 'false', "inSelection": 'true'},
>```
Also, follow this
opened 06:18PM - 23 Jan 20 UTC
closed 01:34PM - 16 Jul 20 UTC
area/upsert
kind/enhancement
## 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": "[email protected] ",
"age": 21
}
],
"infoMe": [
{
"mutation": true,
"total_sum": 1,
"_mutation_": true
}
]
}
}
}
```
