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:
zhangchao 2022-04-16 12:05:06 +08:00
commit e2b8a32b79
5 changed files with 30 additions and 14 deletions

View File

@ -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

View File

@ -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 -->

View File

@ -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.

View File

@ -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

View File

@ -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 \