@@ -73,18 +73,26 @@ message PutObjectRequest {
73
73
// a database-transaction in an all-or-nothing fashion.
74
74
// All Items in a single `PutObjectRequest` must have distinct keys.
75
75
//
76
- // Clients are expected to store a `version` against every `key`.
77
- // The write will succeed if the current DB version against the `key` is the same as in the request.
78
- // When initiating a `PutObjectRequest`, the request should contain their client-side version for
79
- // that key-value.
80
- //
81
- // For the first write of any key, the `version` should be '0'. If the write succeeds, the client
82
- // must increment their corresponding key versions (client-side) by 1.
83
- // The server increments key versions (server-side) for every successful write, hence this
84
- // client-side increment is required to ensure matching versions. These updated key versions should
85
- // be used in subsequent `PutObjectRequest`s for the keys.
76
+ // Key-level versioning (Conditional Write):
77
+ // Clients are expected to store a `version` against every `key`.
78
+ // The write will succeed if the current DB version against the `key` is the same as in the request.
79
+ // When initiating a `PutObjectRequest`, the request should contain their client-side `version`
80
+ // for that key-value.
86
81
//
87
- // Requests with a conflicting version will fail with `CONFLICT_EXCEPTION` as ErrorCode.
82
+ // For the first write of any `key`, the `version` should be '0'. If the write succeeds, the client
83
+ // must increment their corresponding key versions (client-side) by 1.
84
+ // The server increments key versions (server-side) for every successful write, hence this
85
+ // client-side increment is required to ensure matching versions. These updated key versions should
86
+ // be used in subsequent `PutObjectRequest`s for the keys.
87
+ //
88
+ // Requests with a conflicting/mismatched version will fail with `CONFLICT_EXCEPTION` as ErrorCode
89
+ // for conditional writes.
90
+ //
91
+ // Skipping key-level versioning (Non-conditional Write):
92
+ // If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
93
+ // This will perform a non-conditional write query, after which the `version` against the `key`
94
+ // is reset to '1'. Hence, the next `PutObjectRequest` for the `key` can be either
95
+ // a non-conditional write or a conditional write with `version` set to `1`.
88
96
//
89
97
// Considerations for transactions:
90
98
// Transaction writes of multiple items have a performance overhead, hence it is recommended to use
@@ -101,13 +109,20 @@ message PutObjectRequest {
101
109
// Items to be deleted as a result of this `PutObjectRequest`.
102
110
//
103
111
// Each item in the `delete_items` field consists of a `key` and its corresponding `version`.
104
- // The `version` is used to perform a version check before deleting the item.
105
- // The delete will only succeed if the current database version against the `key` is the same as the `version`
106
- // specified in the request.
112
+ //
113
+ // Key-Level Versioning (Conditional Delete):
114
+ // The `version` is used to perform a version check before deleting the item.
115
+ // The delete will only succeed if the current database version against the `key` is the same as
116
+ // the `version` specified in the request.
117
+ //
118
+ // Skipping key-level versioning (Non-conditional Delete):
119
+ // If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
120
+ // This will perform a non-conditional delete query.
107
121
//
108
122
// Fails with `CONFLICT_EXCEPTION` as the ErrorCode if:
109
123
// * The requested item does not exist.
110
- // * The requested item does exist but there is a version-number mismatch with the one in the database.
124
+ // * The requested item does exist but there is a version-number mismatch (in conditional delete)
125
+ // with the one in the database.
111
126
//
112
127
// Multiple items in the `delete_items` field, along with the `transaction_items`, are written in a
113
128
// database transaction in an all-or-nothing fashion.
@@ -133,8 +148,15 @@ message DeleteObjectRequest {
133
148
// Item to be deleted as a result of this `DeleteObjectRequest`.
134
149
//
135
150
// An item consists of a `key` and its corresponding `version`.
136
- // The item is only deleted if the current database version against the `key` is the same as the `version`
137
- // specified in the request.
151
+ //
152
+ // Key-level Versioning (Conditional Delete):
153
+ // The item is only deleted if the current database version against the `key` is the same as
154
+ // the `version` specified in the request.
155
+ //
156
+ // Skipping key-level versioning (Non-conditional Delete):
157
+ // If you wish to skip key-level version checks, set the `version` against the `key` to '-1'.
158
+ // This will perform a non-conditional delete query.
159
+ //
138
160
// This operation is idempotent, that is, multiple delete calls for the same item will not fail.
139
161
//
140
162
// If the requested item does not exist, this operation will not fail.
0 commit comments