Support a new Upsert operation

[manishrjain]

This operation would allow a user to run a query, and use its results (via variables) to execute the mutation. This would then allow upserts to happen, without doing multiple network calls to the DB.

txn {
  query {
    me(func: eq(email, "someone@gmail.com")) {
      v as uid
    }
  }

  mutation @if(eq(len(v), 0)) {
    set {
      <uid(v)> <name> "Some One" .
      <uid(v)> <email> "someone@gmail.com" .
    }
  }
}

This txn would check for an account with email=someone@gmail.com, and only if it is present, would
it run the mutation.

This should return the result of query, normally. And also return the result of the mutation.

Additionally, we should be able to optionally do the mutation, iff the email is already present.

txn {
  query {
    me(func: eq(email, "someone@gmail.com")) {
      v as uid
    }
  }

  mutation @if(gt(len(v), 0)) {
    set {
      <uid(v)> <name> "Changed Name" .
    }
  }
}

This would introduce a new txn operator, and a new if directive applicable for mutations.

[makitka2007]

that would be great

one thing,
imho, blank nodes would have more sense in first case (since v is empty):

mutation @if(eq(len(v), 0)) {
    set {
      _:me <name> "Some One" .
      _:me <email> "someone@gmail.com" .
    }
  }

[liqweed]

@makitka2007 v is empty in case of insert, not so for update. I think the @if() is flexible enough to represent both cases.

[makitka2007]

i see, but in case of insert - what does <uid(v)> mean if v is empty?

for update it's ok, i was talking about first case (insert) only

[srfrog]

uid(v) wont be empty, that's what we are checking with @if(...) that we got an uid list len(list) > 0.

Inside the if(), v represents a set of uid values. Inside the set{} block it represents a value map, so in essence all the mutations inside the block will happen for the uid set given.

[makitka2007]

nope, in first case you are checking for eq(len(v), 0)

[srfrog]

You're right, then I'm not sure what that means.

[srfrog]

The first PR is ready, but blocked by API changes. The syntax changed a bit to not interfere with IRI values. Also, the query is treated as a conditional so if there are no matches and/or no vars generated the mutation won't happen. To test you need the branch in #3197 and hypermodeinc/dgo#50

Ex:

txn {
  // mutation depends on this conditional query matching and yielding 'v'
  query {
    me(func: eq(email, "someone@gmail.com"), first: 1) {
      v as uid
    }
  }
  // needs query above to set 'v'
  mutation {
    set {
      // notice no angle brackets around `uid(v)`
      uid(v) <name> "Changed Name" .
    }
  }
}

Additionally, when using dgo API for a mutation, the field CondQuery can contain the conditional query. It needs to yield a value at least. Finally, the CondQuery is treated as a root query, so it can use query vars $.

[mangalaman93]

I think something like this could work too. upsert could be treated like a keyword like var. We can potentially have more queries in the block. We will only allow one upsert query in a block

{
  me(func: eq(email, "someone@gmail.com"), first: 1) {
      v as uid
    }

  upsert {
      uid(v) <name> "Changed Name" .
  }
}

If there are more than 0 values in v, then, we will do a simple update mutation. If not, in the case, we will generate new UIDs and run the mutations.