mirror of https://github.com/dapr/docs.git
Merge branch 'v1.7' into patch-1
* v1.7: Fixed typo in security concept doc (#2374) [state management] Update docs around transactional operations (#2372) Fixes wrong working directory for dotnet state management sample (#2359) Signed-off-by: zhangchao <zchao9100@gmail.com>
This commit is contained in:
commit
e2b8a32b79
|
@ -138,7 +138,7 @@ By default Dapr doesn't transform the state data from applications. This means D
|
|||
|
||||
However application state often needs to get encrypted at rest to provide stronger security in enterprise workloads or regulated environments and Dapr does provide automatic client side state encryption based on AES256. Read [How-To: Encrypt application state]({{< ref howto-encrypt-state.md >}}) for more details.
|
||||
|
||||
## Dapr Runtrime state
|
||||
## Dapr Runtime state
|
||||
Importantly the Dapr runtime does not store any data at rest, meaning that Dapr runtime has no dependency on any state stores for its operation and can be considered stateless.
|
||||
|
||||
# Using security capabilies in an example application
|
||||
|
|
|
@ -46,4 +46,6 @@ git reset --hard
|
|||
```
|
||||
|
||||
## Related links
|
||||
- [GitHub documentation](https://docs.github.com/en/github/developing-online-with-codespaces/about-codespaces)
|
||||
<!-- IGNORE_LINKS -->
|
||||
- [GitHub documentation](https://docs.github.com/github/developing-online-with-codespaces/about-codespaces)
|
||||
<!-- END_IGNORE -->
|
||||
|
|
|
@ -66,11 +66,17 @@ With the HTTP API, you can set content type via URL query parameter `metadata.co
|
|||
|
||||
With the gRPC API, you can set content type by adding key/value pair `"contentType" : <content type>` to the request metadata.
|
||||
|
||||
### Bulk operations
|
||||
### Multiple operations
|
||||
|
||||
Dapr supports two types of bulk operations: **bulk** or **multi**. You can group several requests of the same type into a bulk (or a batch). Dapr submits requests in bulk operations as individual requests to the underlying data store. In other words, bulk operations are not transactional. On the other hand, you can group requests of different types into a multi-operation, which is then handled as an atomic transaction.
|
||||
Dapr supports two types of mult-read or multi-write operations: **bulk** or **transactional**. Read the [API reference]({{< ref state_api.md >}}) to learn how use bulk and multi options.
|
||||
|
||||
Read the [API reference]({{< ref state_api.md >}}) to learn how use bulk and multi options.
|
||||
#### Bulk read operations
|
||||
|
||||
You can group multiple read requests into a bulk (or batch) operation. In the bulk operation, Dapr submits the read requests as individual requests to the underlying data store, and returns them as a single result.
|
||||
|
||||
#### Transactional operations
|
||||
|
||||
You can group write, update and delete operations into a request, which are then handled as an atomic transaction. The request will succeed or fail as a transactional set of operations.
|
||||
|
||||
### State encryption
|
||||
Dapr supports automatic client encryption of application state with support for key rotations. This is supported on all Dapr state stores. For more info, read the [How-To: Encrypt application state]({{< ref howto-encrypt-state.md >}}) topic.
|
||||
|
|
|
@ -285,7 +285,7 @@ git clone https://github.com/dapr/quickstarts.git
|
|||
In a terminal window, navigate to the `order-processor` directory.
|
||||
|
||||
```bash
|
||||
cd pub_sub/csharp/sdk/order-processor
|
||||
cd state_management/csharp/sdk/order-processor
|
||||
```
|
||||
|
||||
Recall NuGet packages:
|
||||
|
@ -414,7 +414,7 @@ Install the dependencies:
|
|||
mvn clean install
|
||||
```
|
||||
|
||||
Run the `order-processor` publisher service alongside a Dapr sidecar.
|
||||
Run the `order-processor` service alongside a Dapr sidecar.
|
||||
|
||||
```bash
|
||||
dapr run --app-id order-processor --components-path ../../../components -- java -jar target/order-processor-0.0.1-SNAPSHOT.jar
|
||||
|
|
|
@ -443,9 +443,9 @@ POST http://localhost:3500/v1.0-alpha1/state/myStore/query?metadata.partitionKey
|
|||
|
||||
## State transactions
|
||||
|
||||
Persists the changes to the state store as a multi-item transaction.
|
||||
Persists the changes to the state store as a [transactional operation]({{< ref "state-management-overview.md#transactional-operations" >}}).
|
||||
|
||||
> This operation depends on a state store component that supports multi-item transactions.
|
||||
> This API depends on a state store component that supports transactions.
|
||||
|
||||
Refer to the [state store component spec]({{< ref "supported-state-stores.md" >}}) for a full, current list of state stores that support transactions.
|
||||
|
||||
|
@ -481,20 +481,28 @@ POST http://localhost:3500/v1.0/state/myStore/transaction?metadata.contentType=a
|
|||
|
||||
Field | Description
|
||||
---- | -----------
|
||||
`operations` | A JSON array of state operation
|
||||
`metadata` | (optional) The metadata for transaction that applies to all operations
|
||||
`operations` | A JSON array of state `operation`
|
||||
`metadata` | (optional) The `metadata` for the transaction that applies to all operations
|
||||
|
||||
Each state operation is comprised with the following fields:
|
||||
All transactional databases implement the following required operations:
|
||||
|
||||
Field | Description
|
||||
Operation | Description
|
||||
--------- | -----------
|
||||
`upsert` | Adds or updates the value
|
||||
`delete` | Deletes the value
|
||||
|
||||
Each operation has an associated `request` that is comprised of the following fields:
|
||||
|
||||
Request | Description
|
||||
---- | -----------
|
||||
`key` | State key
|
||||
`value` | State value, which can be any byte array
|
||||
`etag` | (optional) State ETag
|
||||
`metadata` | (optional) Additional key-value pairs to be passed to the state store
|
||||
`metadata` | (optional) Additional key-value pairs to be passed to the state store that apply for this operation
|
||||
`options` | (optional) State operation options; see [state operation options](#optional-behaviors)
|
||||
|
||||
#### Examples
|
||||
The example below shows an `upsert` operation for `key1` and a `delete` operation for `key2`. This is applied to the partition named 'planet' in the state store. Both operations either succeed or fail in the transaction.
|
||||
|
||||
```shell
|
||||
curl -X POST http://localhost:3500/v1.0/state/starwars/transaction \
|
||||
|
|
Loading…
Reference in New Issue