Please hide the internal predicates

Experience Report for Feature Request

What you wanted to do

Read my schema. We should hide the internal predicates as they aren’t useful exposed. Also, we could expose them if we set some debug processes or dev mode.

What you actually did

Why that wasn’t great, with examples

Users may get confused by Dgraph’s internal predicates.


<dgraph.cors>: [string] @index(exact) @upsert .
<dgraph.drop.op>: string .
<dgraph.graphql.p_query>: string .
<dgraph.graphql.p_sha256hash>: string @index(exact) .
<dgraph.graphql.schema>: string .
<dgraph.graphql.schema_created_at>: datetime .
<dgraph.graphql.schema_history>: string .
<dgraph.graphql.xid>: string @index(exact) @upsert .


type <dgraph.graphql> {
	dgraph.graphql.schema
	dgraph.graphql.xid
}
type <dgraph.graphql.history> {
	dgraph.graphql.schema_history
	dgraph.graphql.schema_created_at
}
type <dgraph.graphql.persisted_query> {
	dgraph.graphql.p_query
	dgraph.graphql.p_sha256hash
}
type <dgraph.type.cors> {
	dgraph.cors
}
3 Likes

One example of confusion

OMFG YES.

And also we should update the schema{} query to support showing them or not. It’s annoying when you have a 2-3 page long schema and you scroll thru and suddenly <dgraph.graphql.foo>.

3 Likes

Yes. We should hide them. @hardik

2 Likes