Change in behaviour of Schema Type from v1.1.0 to v1.1.1 and v1.2.0

One of many new features in V1.1.0 was the Type system for better describing the Schema used. This also helped for documenting and keeping the underlying ontology consistent with Dgraph.
One of the examples used in the V.1.1.0 documentation is as follows:

type Student {
name: string
dob: datetime
home_address: string
year: int
friends: [uid]

In version1.1.1 (and v.1.2.0) the example has changed to:
type Student {

However I cannot find any trace of this change in the “Migrate to…” section of the documents for version v1.1.1 and v.1.2.0

Unecessary to say, the schema used for V1.1.0 crashes a V1.1.1 instance of dgraph.

Could someone please point me to the appropriate documentation to explain the change of the schema type system?



this was shortly described in the blog post here:

I also remember @MichelDiz writing about it here: Linking types to other Types not working - #4 by MichelDiz

I guess this form of typing things will be used soon in the GraphQL API for dgraph
I am a bit confused why this will be in graphql, but not graphql±, but I guess we’ll know more soon.

The difference is that Dgraph is a DB and the GraphQL is a language layer that we gonna use as an extension of Dgraph DB.

They are two different things, in practice, GraphQL is as if it were just another way to access Dgraph data. As there are databases that allow you to use it as if it were an automatic API. Which will be the case with GraphQL in Dgraph.

It is important to emphasize that GraphQL and GraphQL + - are two separate things that will co-exist. And the entire structure of Dgraph is independent of GraphQL.

Most likely in the future, you will not need to do anything in the context of Dgraph. The GraphQL layer will do just about everything for you on the DB side. But I believe that this will be in the future.


Hi @ppp225 and @MichelDiz

Thank you for taking time to respond to my question.
This was clarifying, and it is then evident to me that I need to continue on v 1.1.0 to avoid that my existing schema crashes the database.

Based on the documentation I could find on it would be wise to avoid any attempt to upgrade, until there are tools for migrating the existing schema into the new one.

If I understood the documentation, taking my existing schema on a v1.1.1 and alter would make all my data inaccessible, since the new schema method changes the underlying data structure?.
e.g. before a type Person {name: string }. would be a “name” field in the database.

And now the from v.1.1.1 a type Person {name: string} would become a field in the database? (which makes sense).

Are you also planning for tools to support migrating data created in v.1.1.0 to a v1.2x series?


For information, I too have avoided upgrading as our codebase relies on the delete UID * * methods and no fixed schema. 1.2 demands a schema to be able to delete nodes - we have several years of development to review in order to accommodate a full schema - it breaks our dynamic integration models.

We’re working on re-engineering our code but it’s a big deal… We also have to shut down, export, update the schema, then reload.

It’s a breaking change that broke a lot of confidence in DG going forward for us.


1 Like

All data created in any DB can be exported and imported to any version. What you can’t do is try to run a different version in a path that has incompatible files for that version

Hi - so that means that I can take my export from v1.1.0 and import it to v1.2.0 with the existing schema for the v1.1.0 and it will all work as before?
Or do I need to adapt my data to the new schema model?

It makes perfect sense to separate the database, and the language used to query the database.
However, when I read the documentation on graphql and the new schema model, to me it seems somewhat strange that the schema (ie. the model of the data) is linked to the query language and not the database?

What I would expect to find is a “schema” or an ontology of the information model we would like to have expressed in the data, upload that schema to the database, and then use graphql (or cypher/gremlin/sparql) to query for the data stored in the database.

One of the strengths of a graph database is that almost any data can be expressed, and that this could happen dynamically. I could upload any type of data, and if I need to query the data, I would then upload a schema of the data. If I need to connect different datasets, I would upload a new schema connecting the two datasets, and then enhance the graph. That is the power of a graph database, and the flexibility to query and find any data that could be connected in the graph.

Anyway - thanks again for the reply

The data exported is just RDF. So, it won’t be a problem.

Well, the schema is another thing. If you need to do adjustments. There’s no other way, you have to do it. I don’t know about this in Dgraph’s GraphQL, but I guess the GraphQL Schema would be implicit in the Dgraph one. Only @michaelcompton can confirm this.

Sorry, I’m not sure what you mean. If you are working with GraphQL, as I said before, it is another story, different from Dgraph’s context. GraphQL has its own context with its own conventions and structure. What is being done in the Schema of GraphQL for Dgraph, is to port the Dgraph functionalities to GraphQL in a way that does not give a lot of work to the end-user (you).

If you are going to work with GraphQL, I recommend you take a break, read the study materials from the GraphQL community (and also from Apollo GraphQL) and understand how GraphQL works. That way you will understand what is happening with the GraphQL feature in Dgraph.

As you are already used to Dgraph, it will not be difficult to understand GraphQL. Because Dgraph is inspired on it. So you will see a lot of similar things, and what is different easily.

From Dgraph?
GraphQL has a Schema that unintentionally simulates an ontology. You can just by reading the schema understand the relations. And also you can run an especial query called “Introspection” that you can use in tools like graphql-voyager (Redirecting to: // so you can see deeply how everything is related. The bad side is that this is just to inspect things, not import or something.


1 Like