The documentation you are viewing is for Dapr v1.9 which is an older version of Dapr. For up-to-date documentation, see the latest version.
Dapr doesn’t transform state values while saving and retrieving states. Dapr requires all state store implementations to abide by a certain key format scheme (see the state management spec. You can directly interact with the underlying store to manipulate the state data, such as:
- Querying states.
- Creating aggregated views.
- Making backups.
NoteThe following examples uses Redis CLI against a Redis store using the default Dapr state store implementation.
Connect to Redis
You can use the official redis-cli or any other Redis compatible tools to connect to the Redis state store to query Dapr states directly. If you are running Redis in a container, the easiest way to use redis-cli is via a container:
docker run --rm -it --link <name of the Redis container> redis redis-cli -h <name of the Redis container>
List keys by App ID
To get all state keys associated with application “myapp”, use the command:
The above command returns a list of existing keys, for example:
1) "myapp||balance" 2) "myapp||amount"
Get specific state data
Dapr saves state values as hash values. Each hash value contains a “data” field, which contains:
- The state data.
- A “version” field, with an ever-incrementing version serving as the ETag.
For example, to get the state data by a key “balance” for the application “myapp”, use the command:
HGET myapp||balance data
To get the state version/ETag, use the command:
HGET myapp||balance version
Read actor state
To get all the state keys associated with an actor with the instance ID “leroy” of actor type “cat” belonging to the application with ID “mypets”, use the command:
To get a specific actor state such as “food”, use the command:
HGET mypets||cat||leroy||food value
WarningYou should not manually update or delete states in the store. All writes and delete operations should be done via the Dapr runtime. The only exception: it is often required to delete actor records in a state store, once you know that these are no longer in use, to prevent a build up of unused actor instances that may never be loaded again.
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.