Dgraph: Feature Request: query-and-mutate-in-one-request

[BlankRain]

https://discuss.dgraph.io/t/query-and-mutate-in-one-request/2390

{
   var(func: has(Postings)) {
       Postings as uid
   }
   mutation {
      <0x938574> <Result> uid(Postings)
   }
}

or

{
   mutation @filter(has(Postings)){
         _:currentNode <lastUpdateTime> now()  # if there is  a now function..
   }
}

[arshedg]

I was searching on the entire documentation expecting querying and mutation is possible. Thanks for this ticket.

[Connectplayltd]

Hopefully, we can get this on the roadmap at some point I know that being able to cut a lot of our requests in half would benefit us substantially.

[mehdiym]

Agreed! "UPDATE WHERE" is supported by all major database and is very useful when you need to mutate millions of predicates, as you can avoid sending them 2 times over the network.

[manishrjain]

I'm honestly not convinced about this. Updating tons of nodes is not something you'd do very frequently. So, running a transaction which can do this in two hops, doesn't seem like it's going to be unmanageably slow.

I'd like to hear if you had reasonable performance issues or other issues while executing it in two-hops using a txn, in an experience report format. Otherwise, it seems like a "nice-to-have" feature, with a bad complexity tradeoff.

[BlankRain]

@manishrjain yes ,you are right. However, it's not so friendly to user when do two-hops in one txn .
In fact, performance is not the only thing we care. we also care whether it is easy for use.
In my opinion , update where... is a kind of syntactic Suger.
Suger is sweet, people like it.

[manishrjain]

Suger is sweet, people like it.

If SQL is sugar, we are selling coffee.

I think @BlankRain does have a point, particularly with the query example he gave at the top. I'm curious to see what other people think their queries might look like. That'd help us figure out how involved this feature would be, and how much could it potentially help the users.

[BlankRain]

Hi, @manishrjain If it's really not necessary, I suggest close this issue.
In my own opinion,SQL is bad , but not too bad ,it still values. I don't want to talk more about SQL here. It's not the key point.
Okay,Let's look at this issue. Why not have a questionnaire survey or some kind of vote to end this issue if possible ?
do a questionnaire survey in community or just a inner team election, whatever else...
Maybe ,it's a better way to know the answer.

[manishrjain]

Let's bring it back to the experience report. I'd like to hear from the participants here, why they'd like this feature. If you can fill it out in this format:

What you wanted to do

What you actually did

Why that wasn't great, with examples

Any external references to support your case

[BlankRain]

What I wanted to do

I want to update nodes with query condition. looks like sql "update xxx set xxx where xxx".

data prepare:

_:jack  <Student> true . # 
_:jack  <Name> Jack . # 
_:jack  <Age> 12 . # 

_:tom  <Student> true . # 
_:tom  <Name> Tom . # 
_:tom  <Age> 22 . # 


_:alice  <Student> true . # 
_:alice  <Name> Danny . # 
_:alice  <Age> 32 . # 

I want to add a tag "GT20" to the node which age is greater than 20.
In sql it may like "update some_table set tag='GT20' where age > 20"

What I actually did

first, I need to get all uids match the condition "> 20".
I query it with query string like that.

query x{
   matchedUids(func: has(Student))@filter(gt(Age,20)){
     uid
  }
}

the response json may like that:

matchedUids:[
{uid:0x02},
{uid:0x03},
....
]

then I extract all values I need to a array, like [0x02,0x03,....].
and then, I build a mutation with this arrays.

mutation{
set{
  <0x02>  <Tag> "GT20" .
  <0x03>  <Tag> "GT20" .
....
}
}

Why that wasn't great, with examples

It troubles a lot.
I need two steps, why can't I do it once. like

queryWithMutation x{
var(has(Student)) @filter(gt(Age,20)){
   matchedUids as uid
}
mutation(func: uid(matchedUids)){
set{
  uid <Tag> "GT20" .
}
}
}

Any external references to support your case

NO.

[manishrjain]

I think there are definitely convincing arguments here. Would be great to get a couple more experience reports, so we can be sure that the complexity is worth it.

[BlankRain]

okay, I will close this issue now . If there are more reports , then we look back.

[mehdiym]

Another reason is the ease of atomic increases/decreases of numeric values.
We can do it currently with 2 hops and a transaction, but it can be complex (code) and slow (indexes, retries).