Metadata-Version: 2.4
Name: pydgraph
Version: 25.1.0
Summary: Official Dgraph client implementation for Python
Author-email: "Istari Digital, Inc." <dgraph-admin@istaridigital.com>
License-Expression: Apache-2.0
Project-URL: Homepage, https://github.com/dgraph-io/pydgraph
Classifier: Intended Audience :: Developers
Classifier: Operating System :: OS Independent
Classifier: Topic :: Database
Classifier: Topic :: Software Development
Classifier: Programming Language :: Python :: 3.9
Classifier: Programming Language :: Python :: 3.10
Classifier: Programming Language :: Python :: 3.11
Classifier: Programming Language :: Python :: 3.12
Classifier: Programming Language :: Python :: 3.13
Classifier: Programming Language :: Python :: 3.14
Requires-Python: >=3.9
Description-Content-Type: text/markdown
License-File: LICENSE
Requires-Dist: grpcio<2.0.0,>=1.65.0
Requires-Dist: protobuf<7.0.0,>=4.23.0
Provides-Extra: dev
Requires-Dist: build>=1.2.2.post1; extra == "dev"
Requires-Dist: grpcio-tools>=1.66.2; extra == "dev"
Requires-Dist: pytest>=8.3.3; extra == "dev"
Requires-Dist: pytest-asyncio>=0.23.0; extra == "dev"
Requires-Dist: ruff>=0.8.4; extra == "dev"
Requires-Dist: ty>=0.0.8; extra == "dev"
Dynamic: license-file

# pydgraph

This is the official Dgraph database client implementation for Python (Python >= v3.9), using
[gRPC](https://grpc.io).

Before using this client, we highly recommend that you read the the product documentation at
[https://docs.dgraph.io/](https://docs.dgraph.io/).

## Table of contents

- [pydgraph](#pydgraph)
  - [Table of contents](#table-of-contents)
  - [Install](#install)
  - [Supported Versions](#supported-versions)
  - [Quickstart](#quickstart)
  - [Using a client](#using-a-client)
    - [Creating a Client](#creating-a-client)
    - [Login into a Namespace](#login-into-a-namespace)
    - [Altering the Database](#altering-the-database)
    - [Creating a Transaction](#creating-a-transaction)
    - [Running a Mutation](#running-a-mutation)
    - [Running a Query](#running-a-query)
    - [Query with RDF response](#query-with-rdf-response)
    - [Running an Upsert: Query + Mutation](#running-an-upsert-query--mutation)
    - [Running a Conditional Upsert](#running-a-conditional-upsert)
    - [Committing a Transaction](#committing-a-transaction)
    - [Cleaning Up Resources](#cleaning-up-resources)
    - [Setting Metadata Headers](#setting-metadata-headers)
    - [Setting a timeout](#setting-a-timeout)
    - [Async methods](#async-methods)
    - [Native Async/Await Client](#native-asyncawait-client)
  - [Handling Transaction Conflicts](#handling-transaction-conflicts)
    - [Using run_transaction (Recommended)](#using-run_transaction-recommended)
    - [Using the Retry Decorator](#using-the-retry-decorator)
    - [Using the Retry Generator](#using-the-retry-generator)
    - [Retry Parameters](#retry-parameters)
    - [Which Errors Are Retried?](#which-errors-are-retried)
    - [Example: High-Contention Counter](#example-high-contention-counter)
  - [Examples](#examples)
  - [Contributing](#contributing)

## Install

Install using pip:

```sh
pip install pydgraph
```

### Protobuf Version Compatibility

pydgraph supports protobuf versions 4.23.0 through 6.x. The specific version installed depends on
your environment:

- **Modern environments**: protobuf 6.x is recommended and will be installed by default on Python
  3.13+
- **Legacy environments**: If you need to use protobuf 4.x or 5.x (e.g., for compatibility with
  other packages), you can pin the version:

```sh
# For protobuf 4.x compatibility
pip install pydgraph "protobuf>=4.23.0,<5.0.0"

# For protobuf 5.x compatibility
pip install pydgraph "protobuf>=5.0.0,<6.0.0"
```

All supported protobuf versions are tested in CI against both Dgraph latest and Dgraph HEAD.

## Supported Versions

Depending on the version of Dgraph that you are connecting to, you should use a different version of
this client. Using an incompatible version may lead to unexpected behavior or errors.

| Dgraph version | pydgraph version |
| :------------: | :--------------: |
|    21.03.x     |    _21.03.x_     |
|    23.0.x+     |     _23.0.x_     |
|    24.0.x+     |     _24.0.x_     |
|    25.0.x+     |     _25.0.x_     |

## Quickstart

Build and run the [simple project][simple] in the `examples` folder, which contains an end-to-end
example of using the Dgraph python client. For additional details, follow the instructions in the
project's [README](./examples/simple/README.md).

[simple]: ./examples/simple

## Using a client

### Creating a Client

You can initialize a `DgraphClient` object by passing it a list of `DgraphClientStub` clients as
variadic arguments. Connecting to multiple Dgraph servers in the same cluster allows for better
distribution of workload.

The following code snippet shows just one connection.

```python
import pydgraph

client_stub = pydgraph.DgraphClientStub('localhost:9080')
client = pydgraph.DgraphClient(client_stub)
```

### Using Dgraph Connection Strings

The pydgraph package supports connecting to a Dgraph cluster using connection strings. Dgraph
connections strings take the form `dgraph://{username:password@}host:port?args`.

`username` and `password` are optional. If username is provided, a password must also be present. If
supplied, these credentials are used to log into a Dgraph cluster through the ACL mechanism.

Valid connection string args:

| Arg         | Value                           | Description                                                                                                                                                   |
| ----------- | ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| bearertoken | \<token\>                       | an access token                                                                                                                                               |
| sslmode     | disable \| require \| verify-ca | TLS option, the default is `disable`. If `verify-ca` is set, the TLS certificate configured in the Dgraph cluster must be from a valid certificate authority. |
| namespace   | \<namespace\>                   | a previously created integer-based namespace, username and password must be supplied                                                                          |

Note the `sslmode=require` pair is not supported and will throw an Exception if used. Python grpc
does not support traffic over TLS that does not fully verify the certificate and domain. Developers
should use the existing stub/client initialization steps for self-signed certs as demonstrated in
[examples/tls/tls_example.py](./examples/tls/tls_example.py).

Some example connection strings:

| Value                                                                                       | Explanation                                                                         |
| ------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- |
| dgraph://localhost:9080                                                                     | Connect to localhost, no ACL, no TLS                                                |
| dgraph://sally:supersecret@dg.example.com:443?sslmode=verify-ca                             | Connect to remote server, use ACL and require TLS and a valid certificate from a CA |
| dgraph://foo-bar.grpc.dgraph-io.com:443?sslmode=verify-ca&bearertoken=\<some access token\> | Connect to a Dgraph cluster protected by a secure gateway                           |
| dgraph://sally:supersecret@dg.example.com:443?namespace=2                                   | Connect to a ACL enabled Dgraph cluster in namespace 2                              |

Using the `Open` function with a connection string:

```python
# open a connection to an ACL-enabled, non-TLS cluster and login as groot
client = pydgraph.open("dgraph://groot:password@localhost:8090")

# Use the client
...

client.close()
```

### Login into a Namespace

If your server has Access Control Lists enabled (Dgraph v1.1 or above), the client must be logged in
for accessing data. If you didn't use the `open` function with credentials and a namespace, use the
`login` endpoint.

Calling `login` will obtain and remember the access and refresh JWT tokens. All subsequent
operations via the logged in client will send along the stored access token.

```python
client.login("groot", "password")
```

If your server additionally has namespaces (Dgraph v21.03 or above), use the `login_into_namespace`
API.

```python
client.login_into_namespace("groot", "password", "123")
```

### Altering the Database

#### Set the Dgraph types schema

To set the Dgraph types schema (aka DQL schema), create an `Operation` object, set the schema and
pass it to `DgraphClient#alter(Operation)` method.

```python
schema = 'name: string @index(exact) .'
op = pydgraph.Operation(schema=schema)
client.alter(op)
```

Indexes can be computed in the background. You can set the `run_in_background` field of
`pydgraph.Operation` to `True` before passing it to the `Alter` function. You can find more details
in the
[Dgraph documentation on background indexes](https://docs.dgraph.io/admin/admin-tasks/update-dgraph-types#indexes-in-background).

**Note** To deploy the GraphQL schema in python you have to use GraphQL client such as
[python-graphql-client](https://github.com/prodigyeducation/python-graphql-client) to invoke the
GraphQL admin mutation [updateGQLSchema](https://docs.dgraph.io/graphql/admin/#modifying-a-schema)

```python
schema = 'name: string @index(exact) .'
op = pydgraph.Operation(schema=schema, run_in_background=True)
client.alter(op)
```

#### Drop data

To drop all data and schema:

```python
# Drop all data including schema from the Dgraph instance. This is a useful
# for small examples such as this since it puts Dgraph into a clean state.
op = pydgraph.Operation(drop_all=True)
client.alter(op)
```

**Note** If the Dgraph cluster contains a GraphQL Schema, it will also be deleted by this operation.

To drop all data and preserve the DQL schema:

```python
# Drop all data from the Dgraph instance. Keep the DQL Schema.
op = pydgraph.Operation(drop_op="DATA")
client.alter(op)
```

To drop a predicate:

```python
# Drop the data associated to a predicate and the predicate from the schema.
op = pydgraph.Operation(drop_op="ATTR", drop_value="<predicate_name>")
client.alter(op)
```

the same result is obtained using

```python
# Drop the data associated to a predicate and the predicate from the schema.
op = pydgraph.Operation(drop_attr="<predicate_name>")
client.alter(op)
```

To drop a type definition from DQL Schema:

```python
# Drop a type from the schema.
op = pydgraph.Operation(drop_op="TYPE", drop_value="<predicate_name>")
client.alter(op)
```

**Note** `drop_op="TYPE"` just removes a type definition from the DQL schema. No data is removed
from the cluster. The operation does not drop the predicates associated with the type.

### Creating a Transaction

To create a transaction, call the `DgraphClient#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.

```python
txn = client.txn()
try:
  # Do something here
  # ...
finally:
  txn.discard()
  # ...
```

To create a read-only transaction, call `DgraphClient#txn(read_only=True)`. Read-only transactions
are ideal for transactions which only involve queries. Mutations and commits are not allowed.

```python
txn = client.txn(read_only=True)
try:
  # Do some queries here
  # ...
finally:
  txn.discard()
  # ...
```

To create a read-only transaction that executes best-effort queries, call
`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
cannot 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.

```python
# Create data.
p = { 'name': 'Alice' }

# Run mutation.
txn.mutate(set_obj=p)

# If you want to use a mutation object, use this instead:
# mu = pydgraph.Mutation(set_json=json.dumps(p).encode('utf8'))
# txn.mutate(mu)

# If you want to use N-Quads, use this instead:
# txn.mutate(set_nquads='_:alice <name> "Alice" .')
```

```python
# Delete data

query = """query all($a: string)
 {
   all(func: eq(name, $a))
    {
      uid
    }
  }"""
variables = {'$a': 'Bob'}

res = txn.query(query, variables=variables)
ppl = json.loads(res.json)

# For a mutation to delete a node, use this:
txn.mutate(del_obj=person)
```

For a complete example with multiple fields and relationships, look at the [simple project][simple]
in the `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.

```python
mutation = txn.create_mutation(set_nquads='_:alice <name> "Alice" .')
request = txn.create_request(mutations=[mutation], commit_now=True)
txn.do_request(request)
```

### Committing a Transaction

A transaction can be committed using the `Txn#commit()` method. If your transaction consist solely
of `Txn#query` or `Txn#queryWithVars` calls, and no calls to `Txn#mutate`, then calling
`Txn#commit()` is not necessary.

An error is raised if another transaction(s) modify the same data concurrently that was modified in
the current transaction. It is up to the user to retry transactions when they fail.

```python
txn = client.txn()
try:
  # ...
  # Perform any number of queries and mutations
  # ...
  # and finally...
  txn.commit()
except pydgraph.AbortedError:
  # Retry or handle exception.
finally:
  # Clean up. Calling this after txn.commit() is a no-op
  # and hence safe.
  txn.discard()
```

#### Using Transaction with Context Manager

The Python context manager will automatically perform the "`commit`" action after all queries and
mutations have been done, and perform "`discard`" action to clean the transaction. When something
goes wrong in the scope of context manager, "`commit`" will not be called,and the "`discard`" action
will be called to drop any potential changes.

```python
with client.begin(read_only=False, best_effort=False) as txn:
  # Do some queries or mutations here
```

or you can directly create a transaction from the `Txn` class.

```python
with pydgraph.Txn(client, read_only=False, best_effort=False) as txn:
  # Do some queries or mutations here
```

> `client.begin()` can only be used with "`with-as`" blocks, while `pydgraph.Txn` class can be
> directly called to instantiate a transaction object.

### Running a Query

You can run a query by calling `Txn#query(string)`. You will need to pass in a
[DQL](https://docs.dgraph.io/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:

```python
# Run query.
query = """query all($a: string) {
  all(func: eq(name, $a))
  {
    name
  }
}"""
variables = {'$a': 'Alice'}

res = txn.query(query, variables=variables)

# If not doing a mutation in the same transaction, simply use:
# res = client.txn(read_only=True).query(query, variables=variables)

ppl = json.loads(res.json)

# Print results.
print('Number of people named "Alice": {}'.format(len(ppl['all'])))
for person in ppl['all']:
  print(person)
```

This should print:

```console
Number of people named "Alice": 1
Alice
```

You can also use `txn.do_request` function to run the query.

```python
request = txn.create_request(query=query)
txn.do_request(request)
```

### Query with RDF response

You can get query result as a RDF response by calling `Txn#query(string)` with `resp_format` set to
`RDF`. The response would contain a `rdf` field, which has the RDF encoded result.

**Note:** If you are querying only for `uid` values, use a JSON format response.

```python
res = txn.query(query, variables=variables, resp_format="RDF")
print(res.rdf)
```

### Running an Upsert: Query + Mutation

The `txn.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](https://docs.dgraph.io/dql/dql-mutation#conditional-upsert).

```python
query = """{
  u as var(func: eq(name, "Alice"))
}"""

nquad = """
  uid(u) <name> "Alice" .
  uid(u) <age> "25" .
"""

mutation = txn.create_mutation(set_nquads=nquad)
request = txn.create_request(query=query, mutations=[mutation], commit_now=True)
txn.do_request(request)
```

### 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 in the Dgraph documentation](https://docs.dgraph.io/dql/dql-mutation#conditional-upsert).

```python
query = """
  {
    user as var(func: eq(email, "wrong_email@dgraph.io"))
  }
"""

cond = "@if(eq(len(user), 1))"
nquads = """
  uid(user) <email> "correct_email@dgraph.io" .
"""

mutation = txn.create_mutation(cond=cond, set_nquads=nquads)
request = txn.create_request(mutations=[mutation], query=query, commit_now=True)
txn.do_request(request)
```

### Cleaning Up Resources

To clean up resources, you have to call `DgraphClientStub#close()` individually for all the
instances of `DgraphClientStub`.

```python
SERVER_ADDR1 = "localhost:9080"
SERVER_ADDR2 = "localhost:9080"

# Create instances of DgraphClientStub.
stub1 = pydgraph.DgraphClientStub(SERVER_ADDR1)
stub2 = pydgraph.DgraphClientStub(SERVER_ADDR2)

# Create an instance of DgraphClient.
client = pydgraph.DgraphClient(stub1, stub2)

# Use client
...

# Clean up resources by closing all client stubs.
stub1.close()
stub2.close()
```

#### Use context manager to automatically clean resources

Use function call:

```python
with pydgraph.client_stub(SERVER_ADDR) as stub1:
  with pydgraph.client_stub(SERVER_ADDR) as stub2:
    client = pydgraph.DgraphClient(stub1, stub2)
```

Use class constructor:

```python
with pydgraph.DgraphClientStub(SERVER_ADDR) as stub1:
  with pydgraph.DgraphClientStub(SERVER_ADDR) as stub2:
    client = pydgraph.DgraphClient(stub1, stub2)
```

Note: `client` should be used inside the "`with-as`" block. The resources related to `client` will
be automatically released outside the block and `client` is not usable any more.

### 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 named "auth-token".

```python
# The following piece of code shows how one can set metadata with
# auth-token, to allow Alter operation, if the server requires it.
# metadata is a list of arbitrary key-value pairs.
metadata = [("auth-token", "the-auth-token-value")]
dg.alter(op, metadata=metadata)
```

### Setting a timeout

A timeout value representing the number of seconds can be passed to the `login`, `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)`

### Async methods

The `alter` 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.

```python
alter_future = self.client.async_alter(pydgraph.Operation(schema="name: string @index(term) ."))
response = pydgraph.DgraphClient.handle_alter_future(alter_future)
```

The `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:

```python
txn = client.txn()
query = "query body here"
future = txn.async_query()
response = pydgraph.Txn.handle_query_future(future)
```

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:

```python
client = DgraphClient(client_stubs) # client_stubs is a list of gRPC stubs.
alter_future = client.async_alter()
try:
    response = alter_future.result()
except Exception as e:
  # You can use this function in the util package to check for JWT
    # expired errors.
    if pydgraph.util.is_jwt_expired(e):
        # retry your request here.
```

### Native Async/Await Client

pydgraph provides a native async/await client using Python's `asyncio` library and `grpc.aio`. This
provides true asynchronous operations with better concurrency compared to the futures-based approach
above.

#### Basic Usage

```python
import asyncio
import pydgraph

async def main():
    # Create async client
    client_stub = pydgraph.AsyncDgraphClientStub('localhost:9080')
    client = pydgraph.AsyncDgraphClient(client_stub)

    try:
        # Login
        await client.login("groot", "password")

        # Alter schema
        await client.alter(pydgraph.Operation(
            schema="name: string @index(term) ."
        ))

        # Run mutation
        txn = client.txn()
        response = await txn.mutate(
            set_obj={"name": "Alice"},
            commit_now=True
        )

        # Run query
        query = '{ me(func: has(name)) { name } }'
        txn = client.txn(read_only=True)
        response = await txn.query(query)
        print(response.json)

    finally:
        await client.close()

asyncio.run(main())
```

#### Using Connection Strings

The async client supports the same connection string format as the sync client:

```python
import asyncio
import pydgraph

async def main():
    # Using async_open with connection string
    async with await pydgraph.async_open(
        "dgraph://groot:password@localhost:9080"
    ) as client:
        version = await client.check_version()
        print(f"Connected to Dgraph version: {version}")

asyncio.run(main())
```

#### Using Context Managers

Both the async client and transactions support async context managers for automatic resource
cleanup:

```python
import asyncio
import pydgraph

async def main():
    # Client auto-closes on exit
    async with await pydgraph.async_open("dgraph://localhost:9080") as client:
        await client.login("groot", "password")

        # Transaction auto-discards on exit
        async with client.txn() as txn:
            response = await txn.query('{ me(func: has(name)) { name } }')
            print(response.json)

asyncio.run(main())
```

#### Concurrent Operations

The async client excels at running many operations concurrently:

```python
import asyncio
import pydgraph

async def run_query(client, name):
    """Run a single query"""
    query = f'{{ me(func: eq(name, "{name}")) {{ name }} }}'
    txn = client.txn(read_only=True)
    return await txn.query(query)

async def main():
    async with await pydgraph.async_open("dgraph://localhost:9080") as client:
        await client.login("groot", "password")

        # Run 100 queries concurrently
        names = [f"User{i}" for i in range(100)]
        tasks = [run_query(client, name) for name in names]
        results = await asyncio.gather(*tasks)

        print(f"Completed {len(results)} queries concurrently")

asyncio.run(main())
```

#### JWT Refresh

The async client automatically handles JWT token refresh, just like the sync client:

```python
async with await pydgraph.async_open("dgraph://groot:password@localhost:9080") as client:
    # JWT will be automatically refreshed if it expires during operations
    response = await client.alter(pydgraph.Operation(schema="name: string ."))
```

#### Error Handling

Error handling works the same as the sync client:

```python
import pydgraph

async def main():
    async with await pydgraph.async_open("dgraph://localhost:9080") as client:
        try:
            await client.login("groot", "wrong_password")
        except Exception as e:
            print(f"Login failed: {e}")

        try:
            txn = client.txn(read_only=True)
            await txn.mutate(set_obj={"name": "Alice"})
        except pydgraph.errors.TransactionError as e:
            print(f"Cannot mutate in read-only transaction: {e}")

asyncio.run(main())
```

#### Differences from Sync Client

| Feature             | Sync Client                 | Async Client                      |
| ------------------- | --------------------------- | --------------------------------- |
| Import              | `pydgraph.DgraphClient`     | `pydgraph.AsyncDgraphClient`      |
| Connection function | `pydgraph.open()`           | `await pydgraph.async_open()`     |
| Method calls        | `client.query()`            | `await client.query()`            |
| Context manager     | `with client.txn() as txn:` | `async with client.txn() as txn:` |
| Concurrency         | Threading                   | Native asyncio                    |
| JWT refresh         | Automatic                   | Automatic                         |

## Handling Transaction Conflicts

Dgraph uses **optimistic concurrency control** (MVCC). When multiple transactions modify the same
data simultaneously, conflicts can occur and Dgraph will abort one of the transactions with an
`AbortedError`. When this happens, the entire transaction must be retried from scratch.

pydgraph provides built-in retry utilities with exponential backoff to handle these conflicts
automatically.

### Using `run_transaction` (Recommended)

The simplest approach - pass your operation as a callable:

```python
import pydgraph

def create_user(txn):
    """Transaction operation that will be retried on conflict."""
    response = txn.mutate(set_obj={"name": "Alice", "age": 30})
    txn.commit()
    return response.uids

client = pydgraph.DgraphClient(pydgraph.DgraphClientStub("localhost:9080"))

# Automatically retries on AbortedError with exponential backoff
result = pydgraph.run_transaction(client, create_user, max_retries=5)
print(f"Created user: {result}")
```

For async code:

```python
async def create_user_async(txn):
    response = await txn.mutate(set_obj={"name": "Alice", "age": 30})
    await txn.commit()
    return response.uids

result = await pydgraph.run_transaction_async(client, create_user_async)
```

### Using the Retry Decorator

Wrap any function that performs Dgraph operations:

```python
import pydgraph

@pydgraph.with_retry(max_retries=5, base_delay=0.1)
def upsert_counter(client, counter_id):
    """Increment a counter atomically - automatically retried on conflict."""
    txn = client.txn()
    try:
        # Query current value
        query = f'{{ counter(func: uid({counter_id})) {{ value }} }}'
        result = txn.query(query)
        current = json.loads(result.json).get("counter", [{}])[0].get("value", 0)

        # Increment and update
        txn.mutate(set_obj={"uid": counter_id, "value": current + 1})
        txn.commit()
    finally:
        txn.discard()

# Called normally - retries happen transparently
upsert_counter(client, "0x123")
```

For async functions:

```python
@pydgraph.with_retry_async(max_retries=5)
async def upsert_counter_async(client, counter_id):
    async with client.txn() as txn:
        # ... async operations
        pass
```

### Using the Retry Generator

For fine-grained control within a function:

```python
import pydgraph

def transfer_funds(client, from_account, to_account, amount):
    """Transfer funds between accounts with manual retry control."""
    for attempt in pydgraph.retry(max_retries=5, base_delay=0.1):
        with attempt:
            txn = client.txn()
            try:
                # Perform the transfer (queries and mutations)
                # If AbortedError is raised, retry() handles it
                txn.commit()
            finally:
                txn.discard()
```

For async code:

```python
async def transfer_funds_async(client, from_account, to_account, amount):
    async for attempt in pydgraph.retry_async(max_retries=5):
        with attempt:
            async with client.txn() as txn:
                # ... async operations
                pass
```

### Retry Parameters

All retry utilities accept these parameters:

| Parameter     | Default | Description                                           |
| ------------- | ------- | ----------------------------------------------------- |
| `max_retries` | 5       | Maximum number of retry attempts                      |
| `base_delay`  | 0.1     | Initial delay in seconds between retries              |
| `max_delay`   | 5.0     | Maximum delay cap in seconds                          |
| `jitter`      | 0.1     | Random jitter factor (0-1) to prevent thundering herd |

### Which Errors Are Retried?

Only these errors trigger automatic retries:

- `pydgraph.AbortedError` - Transaction conflict (optimistic concurrency)
- `pydgraph.RetriableError` - Transient server errors

All other exceptions propagate immediately.

### Example: High-Contention Counter

Here's a complete example handling a high-contention scenario:

```python
import json
import pydgraph

def increment_counter(client, counter_uid):
    """Atomically increment a counter, handling conflicts automatically."""

    def operation(txn):
        # Read current value
        query = f'{{ counter(func: uid({counter_uid})) {{ count }} }}'
        result = txn.query(query)
        data = json.loads(result.json)
        current = data.get("counter", [{}])[0].get("count", 0)

        # Increment
        txn.mutate(set_obj={"uid": counter_uid, "count": current + 1})
        txn.commit()
        return current + 1

    return pydgraph.run_transaction(
        client, operation,
        max_retries=10,   # More retries for high contention
        base_delay=0.05,  # Start with shorter delays
        max_delay=2.0,
        jitter=0.25       # Higher jitter to spread out retries
    )

# Usage
client = pydgraph.DgraphClient(pydgraph.DgraphClientStub("localhost:9080"))
new_value = increment_counter(client, "0x1")
print(f"Counter is now: {new_value}")
```

## Examples

[tls]: ./examples/tls
[parse_datetime]: ./examples/parse_datetime

- [simple][]: Quickstart example of using pydgraph.
- [tls][]: Quickstart example that uses TLS.
- [parse_datetime]: Demonstration of converting Dgraph's DateTime strings to native python datetime.

## Contributing

We welcome contributions! Please see [CONTRIBUTING.md](CONTRIBUTING.md) for detailed information on:
/

- Setting up your development environment
- Code style and standards
- Testing procedures
- Submitting pull requests
