ayorosmage
January 23, 2020, 10:42am
1
For instance, I would like to add an element to a list and in the same request retrieve the new length of the list.
MichelDiz
January 23, 2020, 4:44pm
2
You can use Upser Block - In the response payload of UB query, it comes to a field called "q" or the same name you given to the query. So, after the mutation, it will return the query with the values changed. That can be used for your use case.
Cheers.
ayorosmage
January 23, 2020, 5:05pm
3
According to the documentation:
Execution of an upsert block also returns the response of the query executed on the state of the database before mutation was executed
In my example, I would like to retrieve the lenght of the list after the element was inserted.
MichelDiz
January 23, 2020, 5:20pm
4
humm, is true.
I thought this had resolved, but it looks like you will have to make a second request. Cuz It is not supported.
ayorosmage
January 23, 2020, 5:22pm
5
Ok thank you for your answer.
Do you know if this feature is planned to be implemented ?
MichelDiz
January 23, 2020, 5:27pm
6
ayorosmage
January 23, 2020, 6:03pm
7
Ok !
And just to be sure, given that dgraph is Sequentially Consistent if I perform a read request just after a mutate request, I am sure to retrieve the updated data, that’s right ?
MichelDiz
January 23, 2020, 6:24pm
8
Yes.
BTW I have reformulated the issue
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
}
]
}
}
}
```