We’re overhauling Dgraph’s docs to make them clearer and more approachable. If
you notice any issues during this transition or have suggestions, please
let us know.
The official Python client can be found
here. Follow the install
instructions to get it up
and running.
Supported versions
More details on the supported versions can be found at this link.Using a client
You can get a simple
example
project, which contains an end-to-end working example of how to use the Python
client.
Creating a client
You can initialize aDgraphClient
object by passing it a list of
DgraphClientStub
clients as arguments. Connecting to multiple Dgraph servers
in the same cluster allows for better distribution of workload.
The following code snippet shows just one connection.
Multi-tenancy
In multi-tenancy environments, PyDgraph provides a new methodlogin_into_namespace()
, which allows the users to login
to a specific namespace.
In order to create a python client, and make the client login into namespace
123
:
123
using username
groot
and password password
. Once logged in, the client can perform all the
operations allowed to the groot
user of namespace 123
.
Altering the database
To set the schema, create anOperation
object, set the schema and pass it to
DgraphClient#alter(Operation)
method.
run_in_background
field of pydgraph.Operation
to True
before passing it to the Alter
function. You can find more details
here.
Operation
contains other fields as well, including the drop
predicate and
drop all
. Drop all is useful if you wish to discard all the data, and start
with a clean slate, without bringing the instance down.
Creating a transaction
To create a transaction, call theDgraphClient#txn()
method, which returns a
new Txn
object. This operation incurs no network overhead.
It is good practice to call Txn#discard()
in a finally
block after running
the transaction. Calling Txn#discard()
after Txn#commit()
is a no-op and you
can call Txn#discard()
multiple times with no additional side-effects.
DgraphClient#txn(read_only=True)
.
Read-only transactions are ideal for transactions which only involve queries.
Mutations and commits aren’t allowed.
DgraphClient#txn(read_only=True, best_effort=True)
. Best-effort queries are
faster than normal queries because they bypass the normal consensus protocol.
For this same reason, best-effort queries can’t guarantee to return the latest
data. Best-effort queries are only supported by read-only transactions.
Running a mutation
Txn#mutate(mu=Mutation)
runs a mutation. It takes in a Mutation
object,
which provides two main ways to set data, JSON and RDF N-Quad. You can choose
whichever way is convenient.
Txn#mutate()
provides convenience keyword arguments set_obj
and del_obj
for setting JSON values and set_nquads
and del_nquads
for setting N-Quad
values. See examples below for usage.
We define a person object to represent a person and use it in a transaction.
examples
folder.
Sometimes, you only want to commit a mutation, without querying anything
further. In such cases, you can set the keyword argument commit_now=True
to
indicate that the mutation must be immediately committed.
A mutation can be executed using txn.do_request
as well.
Committing a transaction
A transaction can be committed using theTxn#commit()
method. If your
transaction consist solely of Txn#query
or Txn#queryWithVars
calls, and no
calls to Txn#mutate
, then calling Txn#commit()
isn’t necessary.
An error is raised if another transaction modifies the same data concurrently
that was modified in the current transaction. It is up to the user to retry
transactions when they fail.
Running a query
You can run a query by callingTxn#query(string)
. You need to pass in a
DQL query string. If you want to pass an additional
dictionary of any variables that you might want to set in the query, call
Txn#query(string, variables=d)
with the variables dictionary d
.
The query response contains the json
field, which returns the JSON response.
Let’s run a query with a variable $a
, deserialize the result from JSON and
print it out:
txn.do_request
function to run the query.
Running an upsert: query + mutation
Thetxn.do_request
function allows you to use upsert blocks. An upsert block
contains one query block and one or more mutation blocks, so it lets you perform
queries and mutations in a single request. Variables defined in the query block
can be used in the mutation blocks using the uid
and val
functions
implemented by DQL.
To learn more about upsert blocks, see the
Upsert Block documentation.
Running a conditional upsert
The upsert block also allows specifying a conditional mutation block using an@if
directive. The mutation is executed only when the specified condition is
true. If the condition is false, the mutation is silently ignored.
See more about Conditional Upserts
here.
Cleaning up resources
To clean up resources, you have to callDgraphClientStub#close()
individually
for all the instances of DgraphClientStub
.
Setting metadata headers
Metadata headers such as authentication tokens can be set through the metadata of gRPC methods. Below is an example of how to set a header namedauth-token
.
Setting a timeout
A timeout value representing the number of seconds can be passed to thelogin
,
alter
, query
, and mutate
methods using the timeout
keyword argument.
For example, the following alters the schema with a timeout of ten seconds:
dg.alter(op, timeout=10)
Passing credentials
ACallCredentials
object can be passed to the login
, alter
, query
, and
mutate
methods using the credentials
keyword argument.
Authenticating to a reverse TLS proxy
If the Dgraph instance is behind a reverse TLS proxy, credentials can also be passed through the methods available in the gRPC library. Note that in this case every request needs to include the credentials. In the example below, we’re trying to add authentication to a proxy that requires an API key. This value is expected to be included in the metadata using the keyauthorization
.
Async methods
Thealter
method in the client has an asynchronous version called
async_alter
. The async methods return a future. You can directly call the
result
method on the future. However. The DgraphClient class provides a static
method handle_alter_future
to handle any possible exception.
query
and mutate
methods int the Txn
class also have async versions
called async_query
and async_mutation
respectively. These functions work
just like async_alter
.
You can use the handle_query_future
and handle_mutate_future
static methods
in the Txn
class to retrieve the result. A short example is given below:
test_asycn.py
test file.
Keep in mind that due to the nature of async calls, the async functions cannot
retry the request if the login is invalid. You will have to check for this error
and retry the login (with the function retry_login
in both the Txn
and
Client
classes). A short example is given below: