Overview
Implementation
Clients can communicate with the server in two different ways:
-
Via gRPC: internally this uses Protocol Buffers (the proto file used by Dgraph is located at api.proto).
-
Via HTTP: there are various endpoints, each accepting and returning JSON. There is a one to one correspondence between the HTTP endpoints and the gRPC service methods.
It’s possible to interface with Dgraph directly via gRPC or HTTP. However, if a client library exists for you language, this will be an easier option.
*grpc.ClientConn
per Dgraph instance. Mutations will be made in a round robin
fashion, resulting in an initially semi random predicate distribution.
Transactions
Dgraph clients perform mutations and queries using transactions. A transaction bounds a sequence of queries and mutations that are committed by Dgraph as a single unit: that is, on commit, either all the changes are accepted by Dgraph or none are.
A transaction always sees the database state at the moment it began, plus any changes it makes — changes from concurrent transactions aren’t visible.
On commit, Dgraph will abort a transaction, rather than committing changes, when a conflicting, concurrently running transaction has already been committed. Two transactions conflict when both transactions:
- write values to the same scalar predicate of the same node (e.g both
attempting to set a particular node’s
address
predicate); or - write to a singular
uid
predicate of the same node (changes to[uid]
predicates can be concurrently written); or - write a value that conflicts on an index for a predicate with
@upsert
set in the schema (see upserts).
When a transaction is aborted, all its changes are discarded. Transactions can be manually aborted.