Problem while using uid in if condition in a conditional upsert operation

Users Dgraph
1 
upsert{
  query{
    var (func: eq(user.name, "Matt")){
       id as uid
    }
  }
  mutation @if(eq(val(id), 0x001)){
    set{
      uid(id) <user.job> "Engineer"
    }
  }
}

In this case, the if condition does not return true which will in turn execute the set operation. I know for the fact that user Matt’s uid is 0x001 and even when the var block is used separately as a query block to display Matt’s uid, it displays 0x001 but, the if condition does not return true.

EDIT : changed the previous if condition from @if(val(id), 0x001) to @if(eq(val(id), 0x001)) which was the intended query

2

This isn’t supported. Conditional upserts accepts length functions only, no other feature. Length is the recommended function for this case.

e.g:

upsert {
  query {
    ID  as var(func: eq(user.name, "Matt"))
    check as var(func: uid(ID)) @filter(uid(0x001))
  }

  mutation @if(eq(len(check), 1) ) {
    set {
      uid(check) <user.job> "Engineer"
    }
  }
}
3

But, this only ensures the existence of the uid but it wouldn’t make sure if check is equal to a uid that you might want to give as an operand to eq function. Am I right?

4

The filter @filter(uid(0x001)) guarantees to you that. So, if “Matt” uid isn’t equal to 0x001 it will fail and it will return a length of 0. If it is equal to 0x001 it will succeed and return a length of 1 and execute the mutation in the upsert block.

Actually, you don’t need the “check” block, you can do that in the first block. I did it this way to be visually didactic.

5

Sounds like a good workaround.

6

BTW see this issue - Really curious that the interest on this has increased in the last 24 hours.

7

That sounds great, now we can put conditional upsert to extensive with the addition of other functions inside if.

8

Hi, I have a similar use case. Is it in the roadmap to add other different conditions in the conditional upsert like comparing with a value of a variable?

Although it can be solved in the way you indicate, I find it a bit strange having to make another query to have a length.

Thanks!

9

I don’t think this has priority. Let me ping @hardik.

10

Added this to items to be considered for Roadmap :slight_smile:.

@MIguel_Angel_Esteve and @shravan we will keep you posted. But it would take less priority as of now so we do recommend to use the solution suggested above.

11

Great! Yes, I’ll use the current solution in the meantime.
Thank you very much, I think that can simplify the code to use if we follow that path.

12

can we use else here along with if