Shuri (20.07.0) does not auto-populate dgraph.graphql instance

Issues Dgraph
1

When I query my v20.03.4 cluster with:

{
  result (func: has(<dgraph.graphql.schema>)) {
    uid
    <dgraph.graphql.schema>
    <dgraph.graphql.xid>
    <dgraph.type>
  }
}

I get the following result:

{
  "uid": "0x1",
  "dgraph.graphql.schema": "",
  "dgraph.graphql.xid": "dgraph.graphql.schema",
  "dgraph.type": [
    "dgraph.graphql"
  ]
}

When I start the cluster fresh and clean with:

docker run --rm -it -p 8080:8080 -p 9080:9080 -p 8000:8000 -p 6080:6080 dgraph/dgraph:v20.03.04 /bin/bash -c "dgraph-ratel & dgraph zero & dgraph alpha --lru_mb 1024 --whitelist 0.0.0.0/0"

it will auto-create that instance of type dgraph.graphql, hence uid 0x1.

This behaviour is the case for v20.03.3 and v20.03.4, this does not happen with v20.03.0, v20.03.1, v20.03.2 and v20.07.0 (shuri).

Is this behaviour expected to have been removed again with 20.07.0?

I am regression testing my code against a Dgraph test cluster and I now have to work around this behaviour change moving to 20.07.0.

2

Yes, it has been changed in 20.07.0 and will remain the same for the foreseeable future.

We had switched to auto creating a node for storing GraphQL schema for some time in between, but later we discovered some issues which forced us to rethink how GraphQL schema should be stored. Now, the GraphQL schema node is created only when someone sends a GraphQL schema update, and not in advance.

See this topic and this PR for more details.

4 Likes
3

Thanks for clarification. Is there a way to create that empty graphql schema via API call as it exists for 20.03.3 and 20.03.4? When I try to create an empty schema I get an exception:

$ curl "localhost:8080/admin/schema" -XPOST -d ''
{"errors":[{"message":"resolving updateGQLSchema failed because input: No schema specified (Locations: [{Line: 3, Column: 4}])","extensions":{"code":"Error"}}]}

So it looks like it is impossible to create this from outside:

{
  "uid": "0x1",
  "dgraph.graphql.schema": "",
  "dgraph.graphql.xid": "dgraph.graphql.schema",
  "dgraph.type": [
    "dgraph.graphql"
  ]
}

Upserting <dgraph.graphql.schema> is also not allowed:

upsert {
  query {
    q(func: eq(<dgraph.graphql.xid>, "dgraph.graphql.schema")) {
      graphql as uid
    }
  }

  mutation {
    set {
      uid(graphql) <dgraph.graphql.schema> "" .
      uid(graphql) <dgraph.graphql.xid> "dgraph.graphql.schema" .
      uid(graphql) <dgraph.type> "dgraph.graphql" .
    }
  }
}

fails with

{
  "name": "t",
  "url": "http://localhost:8080/mutate?commitNow=true",
  "errors": [
    {
      "message": "Cannot mutate graphql reserved predicate dgraph.graphql.schema",
      "extensions": {
        "code": "ErrorInvalidRequest"
      }
    }
  ]
}
4

No, that is an internal node, and there is no way to create it from outside.

5

And there is no way to create an empty GraphQl schema? Like deleting / dropping the schema would not set <dgraph.graphql.schema> to ""?

6

Huh, you could do that.
You can first send a valid GraphQL schema, then do a drop_all. That will set <dgraph.graphql.schema> to "". That should work.
But, there is no guarantee that the uid assigned to this node would be <0x1>. You will have to update the GraphQL schema as the first operation after you start dgraph cluster, to get that exact uid.

This is how you can do drop_all:

$ curl -X POST localhost:8080/alter -d '{"drop_all": true}'

This will remove all the data from the dgraph cluster, and set the <dgraph.graphql.schema> to "".

7

Great, I can confirm that drop_all produces the dgraph.graphql node with dgraph.graphql.schema = "" in 20.07.0, so I can get that version into the same state as 20.03.3 and 20.03.4, though it does not work before 20.03.3, but that is fine. It works with a fresh started Shuri cluster, so no need to add a GraphQL schema in the first place. I hope this behaviour stays over the next versions.

The unpredictable uid for that node is fine, I am already working around that.

Thanks a lot!