Closed Andrea-Scuderi closed 1 year ago
Swift 5.8 failed https://github.com/soto-project/soto/actions/runs/5275592595/jobs/9541238015?pr=673#step:5:8784
Maybe localstack getting it wrong though
Swift 5.8 failed https://github.com/soto-project/soto/actions/runs/5275592595/jobs/9541238015?pr=673#step:5:8784
Maybe localstack getting it wrong though
The age in the example was updated to 33 to prove that conditional update works when executed against the last update. All seems ok. Still in doubt if It's better to have explicit parameter for additionalAttributeNames. For implementing optimistic locking this seems enough.
Just re-running the tests. I can't get them to fail locally with local stack.
671 has introduced a new method to initialize UpdateItemCodableInput, but it has introduced an issue.
Consider the following code:
The intention of the previous code is to update the item only when the key exists and when the record to update has the same createdAt and updatedAt data stored in DynamoDB. The update will change updatedAt with a new timestamp. In this way a client that doesn't have the same item cannot update the DynamoDB table and is forced to read the item before an update. (Optimistic locking)
But it leads to the following exception:
To fix the issue the code has be changed to include only the key in additionalAttributeNames and avoiding to add attributes that are not used.
The client code can be fixed by using:
In the Unit Tests, the optimistic locking has been tested using
id
as key andage
as condition to validate the record.An alternative solution could be to add an explicit parameter to additionalAttributeNames.