Whats new in Dgraph v1.1.0?

Table of contents

Reading Time: 3 minutes

In this blog, we will cover the new features Introduced in Dgraph v1.1.0 which was released on 3rd September. We can also find the breaking changes in dgraph v1.1.0 . Also, we can find all the changes and new features detail in the change-log.

New Type System

This version of Dgraph supports a type system that can be used to categorize nodes and query them based on their type. It allows grouping of nodes into sets describing the data associated with them. Types are declared along with the schema. using the Alter endpoint.

type student {
        name: string,
     	age: int,
	address: string
} 
name: string@index(term) .
age: int .
address: string

The type can be set by setting the value of the dgraph.type predicate for a node as shown below:

{
	Set {
		_:amit <name> “Amit” .
		_:amit <age> 20 .
		_:amit <address> “xyz” .
		_:amit <dgraph.type> “student” .
           }
}

NOTE: Scalar nodes cannot have types because they have only one attribute And its type is the type of the node.

Type System only makes entity handling easier, it does not provide type safety because we can add predicates and edges to the schema which are not defined in the type.

Upsert Block

Before this release of Dgraph, the upsert was a two step process. First run a query to see if the value exists and then create it if not.

For example we have to create a new user with ID and Name information. We also want to make sure that one ID has exactly one corresponding user in the database. So, to achieve this the two steps to be followed:
1. First, send a query to find whether a user exists with a given ID.
2. Then, if no user was found with that ID, use a mutation to create it.

With the new upsert block feature, upserts can be performed in one step. The upsert block allows performing queries and mutations in a single request. The upsert block contains one query block and one mutation block. Variables defined in the query block can be used in the mutation block using the uid function. The schema for above example is:

Name: string @index(term) .
ID: int @index(int) @upsert .
age: int @index(int) .

Now let’s create a new user with ID 123 and name userName by the help of upsert block as shown below:

upsert {
  query {
    v as var(func: eq(ID, 123))
  }
  mutation {
    set {
      uid(v) &lt;name> "userName" .
      uid(v) &lt;ID> 123 .
    }
  }
}

The query part of the upsert block stores the UID of the user with the provided ID in the variable v. The mutation part then extracts the UID from variable v, and stores the Name and ID information in the database. If the user exists, the information is updated otherwise uid(v) is treated as a blank node and a new user is created.

Access Control Lists

Access Control Lists (ACL) is a part of Dgraph’s enterprise feature which provide access protection to our data stored in Dgraph. When the ACL feature is turned on, a client must authenticate with a username and password before executing any transactions and is only allowed to access the data permitted by the ACL rules. We can find more information about ACL docs .

Binary Backups

Binary backups are part of Dgraph’s enterprise features. Backup can be stored directly on our on-premise or cloud storage systems and then they can be used to restore a new Dgraph cluster to the previous state. We can learn more about Binary Backups reading the Binary Backup documentation page.

Conclusion

In this blog we have seen some of the exciting features introduced in this version. To know more about all the changes, bug-fixes, and enhancements in this release, read change-log.