Reading Time: 4 minutes

Dgraph v1.1.0 was released on 3rd September, 2019 with significant changes and new features. So, It becomes important to know these changes that could break our existing code when we try to upgrade Dgraph with the new version. In this blog, we will cover the important changes introduced. We can find all the changes and new features detail in the change-log.

1. Predicates of type UID lists are now defined as [uid].

Before this release, a predicate defined as type uid was interpreted as predicate of type list of UIDs. It was difficult to say that a predicate could have a single UID value. In this release, to indicate that a predicate has a list of UIDs associated with it, we will use [uid] because uid now means the value is a single UID.

For example, to store Authors and their corresponding blogs in Dgraph we have a graph model:

The schema for the above model is:

author_name: string @index(term) .
published: [uid] .

Let’s perform a mutation to add authors and their corresponding blogs in the database.

{
	set : [ 
     {
		"author_name": "John Campbell"
		"published": [
    			{
    			 "title": "Dgraph's recap of GraphQL Conf -              
                          Berlin 2019"
                        }
                        {
                         "title": "Dgraph Labs wants you!",
                        }
 
               "author_name": "John Travis",
               "published": [
                       {
                         "title": "How Dgraph Labs Raised Series A",
		       }
		       {
			"title": "Celebrating 10,000 GitHub Stars",
                       }
                             ]
       } 
 ]
}

Here each author has more than one blog post so, the published predicate must be of type uid array.

[uid]  indicates that there could be more than one published edge emerging from a given author node, each pointing to a different blog post of the author. But if there is a scenario where each author has only one blog then there is only one edge from the author node pointing to the corresponding blog. In that case, the published predicate must be of type uid instead of [uid].

2. Removal of _predicate_ keyword

The keyword _predicate_ is removed from the query language. Basically, we can consider _predicate_ to be a predicate of type [string] that was internally maintained by Dgraph. Every time a node updates, so does it’s predicate. Usually, when an update happens, it goes through the Dgraph’s consensus protocol (RAFT) to ensure Dgraph consistency. This updates every node’s predicate touched by the mutation, which in turn guarantees the consistency of _predicate_ to be very costly.

The other performance concern is that Dgraph stores this predicate for every node in the graph. This consumes a lot of storage. Ultimately, the lack of consistency and the storage costs caused to drop support for _predicate_ keyword in Dgraph v1.1.0.

3. Change in behavior of expand(_all_)

In v1.1.0, expand(_all_) only works for nodes with attached type information via the type system which is a new feature in Dgraph v1.1.0. The type system determines the predicates to expand out from a node. For example, consider a node with uid xc1302 that has types Animal and Pet, which have the following definitions:

type Animal {
    name
    species
    dob
}
type Pet {
    owner
    veterinarian
}

When expand(_all_) executes on this node, Dgraph first checks the type of the node (Animal and Pet). Then it gets the definitions of Animal and Pet and finally builds a list of predicates from their type definitions.

{
  query(func: uid(xc1302)) {
   expand(_all_)
     }
}

The above query yields the result with all predicates defined in type Animal and Pet (name, species, dob, owner, and veterinarian ) and their values for the node of uid xc1302.

NOTE: If any predicate is added that is not defined in the type system, expand(_all_) query does not yield it’s result.

4. Change in behavior of * in delete operations

Performing a delete operation with * deletes only the predicates of the types associated with a given node. For example, consider a node with uid 0x1c3eb that has a type of Animal and the following definition:

type Animal {
    name
    species
    dob
}

When S** delete operationexecutes on this node, Dgraph first checks the type of the node (Animal), then it gets the definition of Animal and removes it’s list of Predicates.

{ 
Delete {
<0x1c3eb> * * .
   }
}

For a predicate owner not defined in type Animal, S** does not delete it for this node.

5. Changes in HTTP header

This version of Dgraph dropped support for the HTTP headers X-Dgraph-CommitNow and X-Dgraph-MutationType. Instead of X-Dgraph-MutationType, Dgraph uses the standard HTTP header Content-Type, and X-Dgraph-CommitNow is now a query parameter in the URL commitNow=true as shown below in curl request.

curl -H "Content-Type: application/rdf" -X POST localhost:8080/mutate?commitNow=true -d $'
{
  set {
    _:alice <name> "Alice" .
  }
}'

This change should only affect applications that are directly using Dgraph’s REST endpoints. But if using a client library, these changes should be fully transparent.

Conclusion

In this blog we went through five breaking changes in version 1.1.0 that must be absorbed in our current code because it might break our code when we try to upgrade our Dgraph with newer version. To know more about all the changes, bug-fixes, and enhancements in this release, read the change-log. This blog will help us to make changes in our application when we migrate to Dgraph v1.1.0.

References

https://docs.dgraph.io
https://blog.dgraph.io/post/release-v1.1.0/
https://github.com/dgraph-io/dgraph/blob/master/CHANGELOG.md#110—2019-09-03