Skip to content

Support raise exception/error on upsert block #4500

@ChStark

Description

@ChStark

What you wanted to do

If we see the documentation, we can find an example of an upsert like this

upsert {
  query {
    q(func: eq(email, "user@company1.io")) {
      v as uid
      name
    }
  }

  mutation{
    set {
      uid(v) <name> "first last" .
      uid(v) <email> "user@company1.io" .
    }
  }
}

Wich is ok if you want to do the actual upsert, but most often than not, we need to not insert data if the data is present, according to the docs of the conditional upsert The upsert block also allows specifying conditional mutation blocks using an @if directive. The mutation is executed only when the specified condition is true. If the condition is false, the mutation is silently ignored

What you actually did

Since we can ensure to not store repeated information with the @if directive, we need to look up on the response to see if the mutation created a new node or the query to see if the query got a result.

what I did

upsert {
  query {
    q(func: eq(email, "user@company1.io")) {
      v as uid
      name
    }
  }

  mutation @if( eq( len( v ) , 0 ) ){
    set {
      _:new <name> "first last" .
      _:new <email> "user@company1.io" .
    }
  }
}

And then look on the response if data.uids.new contains a new id

Why that wasn't great, with examples

Is not great to need to inspect for each possible outcome of the mutation, it would be great if upsert block support intentional fails, something like

upsert {
  query {
    q(func: eq(email, "user@company1.io")) {
      v as uid
      name
    }
  }

  raise @if( lt( len( v ) , 0 ) ) {
    exception("Email was already on the database") #and rollback the transaction automatically
   #notice( "..." ) if it shouldn't stop transaction, but the message should be included on the response
  }

  mutation{ #we no longer need to add the @if directive here
    set {
      _:new <name> "first last" .
      _:new <email> "user@company1.io" .
    }
  }
}

Or something like that

Any external references to support your case

We can take the RAISE keyword from plpsql docs
https://www.postgresql.org/docs/9.3/plpgsql-errors-and-messages.html

Metadata

Metadata

Assignees

No one assigned

    Labels

    area/upsertIssues related to upsert operations.kind/enhancementSomething could be better.status/more-info-neededThe issue has been sent back to the reporter asking for clarifications

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions