Support GraphQL variables in mutations

Moved from GitHub dgraph/4615

Posted by F21:

Experience Report

What you wanted to do

I want to perform a mutation in an upsert block using user-provided data safely.

What you actually did

upsert ($name: string){
      query {
        var(func: eq(xid, "http://schema.org/Person")) {
          Type as uid
        }
        var(func: eq(<http://schema.org/name>, "Robin Wright")) {
          Person as uid
        }
      }
      mutation {
          set {
           uid(Person) <xid> "https://www.themoviedb.org/person/32-robin-wright" .
           uid(Person) <http://schema.org/type> uid(Type) .
           uid(Person) <http://schema.org/name> $name .
           uid(Person) <dgraph.type> "Person" .
          }
      }
    }

Why that wasn’t great, with examples

GraphQL variables are not supported in mutations, so it’s impossible to safely mutate user-provided data without error-prone validation.

Any external references to support your case

None at the moment.

miko commented :

I also support this request. The rationale is the same as for GraphQL variables in queries: https://docs.dgraph.io/query-language/#graphql-variables

MichaelJCompton commented :

This looks like a reasonable feature request.

I’m tagging it as accepted, which means it will get into our backlog of features to consider.

If we decide to implement it, we’ll post an update here.

I just ran into this as well. Do you know if there has been a decision about whether this will be implemented?

1 Like

@hardik do you have any idea?

1 Like

Just to provide some more context. In my specific case I needed to pass a Uid variable. This is pretty easy to validate before concatenating with the query string.

In cases where the variable is some sort of free-form string originating from a client, it would be very difficult to ensure the upsert query isn’t being injected. Essentially all the same reasons GraphQL variables are supported in standard queries.

But like I said, for Uids this isn’t much of an issue beyond having to prepare the requests a little differently.