Optimistic locking for delete scenario with TransactWriteItemsEnhancedRequest

[roamariei]

Description

Optimistic locking while using DynamoDbEnhancedClient - DeleteItem with TransactWriteItemsEnhancedRequest

Motivation and Context

#2358

Modifications

• Modified addDeleteItem method in TransactWriteItemsEnhancedRequest to invoke a new method, generateTransactDeleteItem, which includes an additional parameter: Map<String, AttributeValue> itemMap.
• Redirected delete operations to an internal method that constructs the version check condition.
• Added an internal BeforeDelete interface, similar to BeforeWrite, to handle version validation before execution. The implementation of this method was placed in VersionedRecordExtension and called from DeleteItemOperation.

Testing

Added unit tests for ChainExtension, VersionRecordTest and integration tests for delete scenario with matching version and with exception if the version mismatch.

Screenshots (if appropriate)

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)

Checklist

• I have read the CONTRIBUTING document
• Local run of mvn install succeeds
• My code follows the code style of this project
• My change requires a change to the Javadoc documentation
• I have updated the Javadoc documentation accordingly
• I have added tests to cover my changes
• All new and existing tests passed
• I have added a changelog entry. Adding a new entry must be accomplished by running the scripts/new-change script and following the instructions. Commit the new file created by the script in .changes/next-release with your changes.
• My change is to implement 1.11 parity feature and I have updated LaunchChangelog

License

• I confirm that this pull request can be released under the Apache 2 license

[joviegas]

This is a breaking change right ?

What if currently user was using this API to delete any API m and such cases we will start getting exceptions ?

[anasatirbasa]

This is a breaking change right ?

What if currently user was using this API to delete any API m and such cases we will start getting exceptions ?

Hello, @joviegas

This is not a breaking change, as described in the Solution Proposal. A validation step was added to ensure that the version in the delete request matches the version stored in the database.

If the versions do not match, the operation now throws a TransactionCanceledException, which is the expected behavior for conditional operations in DefaultDynamoDbClient in case a condition (in one of the condition expressions) is not met. This scenario is covered by the integration test deleteItemWithTransactWrite_shouldFailIfVersionMismatch in CrudWithResponseIntegrationTest.java.

Before the changes from the current PR, the item would have been deleted even if the version did not match, and no exception was thrown. The new behavior enforces optimistic locking to improve data integrity.

[joviegas]

This is a breaking change right ?
What if currently user was using this API to delete any API m and such cases we will start getting exceptions ?

Hello, @joviegas

This is not a breaking change, as described in the Solution Proposal. A validation step was added to ensure that the version in the delete request matches the version stored in the database.

If the versions do not match, the operation now throws a TransactionCanceledException, which is the expected behavior for conditional operations in DefaultDynamoDbClient in case a condition (in one of the condition expressions) is not met. This scenario is covered by the integration test deleteItemWithTransactWrite_shouldFailIfVersionMismatch in CrudWithResponseIntegrationTest.java.

Before the changes from the current PR, the item would have been deleted even if the version did not match, and no exception was thrown. The new behavior enforces optimistic locking to improve data integrity.

Right now, customers can delete items without worrying about versions, and it just works. But after our update, they're going to start getting TransactionCanceledException errors out of nowhere.

Think about it this way: let's say someone has code that tries to delete item X with version 1. They don't really care if the actual version is 2 or 3 - they just want the item gone. Today, that works fine. Tomorrow, after they upgrade, boom - exception thrown and their code breaks.

That's a classic breaking change. Their apps that work perfectly today will suddenly fail. They'll have to go in and modify their code to handle these new exceptions. And there's no way for them to get the old "just delete it" behavior back without changing their code.

Don't get me wrong - I totally get that this change makes things better from a data integrity standpoint with the optimistic locking. Some customers probably built their apps specifically counting on that "delete regardless of version" behavior.
We need to think of approach which is not breaking the existing customers. What do you think?

[anasatirbasa]

Hello @joviegas,
 
From this standpoint indeed it would be a breaking change. To address the potential breaking change and ensure full backward compatibility while introducing optimistic locking support, we propose the addition of a new overload for the addDeleteItem API:

• Current method signature (no Optimistic Locking support):
  public <T> Builder addDeleteItem(MappedTableResource<T> mappedTableResource, T keyItem)

• Proposed overload (with Optimistic Locking support):
  public <T> Builder addDeleteItem(MappedTableResource<T> mappedTableResource, T keyItem, Boolean useOptimisticLocking)
   

The current method will internally delegate to the new method using useOptimisticLocking = false, thereby maintaining the existing "delete regardless of version" behavior without introducing any breaking change.
Developers who opt in to optimistic locking can explicitly call the new overload with useOptimisticLocking = true, which will enforce version checks during deletion and improve data integrity.

We will refactor the tests to add coverage on both current and new behavior. This approach allows us to introduce the feature in a backward-compatible manner, giving users the choice to adopt the new behavior at their discretion.

We look forward to your feedback on this approach.

[joviegas]

Hello @joviegas, From this standpoint indeed it would be a breaking change. To address the potential breaking change and ensure full backward compatibility while introducing optimistic locking support, we propose the addition of a new overload for the addDeleteItem API:

* Current method signature (no Optimistic Locking support):
  `public <T> Builder addDeleteItem(MappedTableResource<T> mappedTableResource, T keyItem)`

* Proposed overload (with Optimistic Locking support):
  `public <T> Builder addDeleteItem(MappedTableResource<T> mappedTableResource, T keyItem, Boolean useOptimisticLocking)`

The current method will internally delegate to the new method using useOptimisticLocking = false, thereby maintaining the existing "delete regardless of version" behavior without introducing any breaking change. Developers who opt in to optimistic locking can explicitly call the new overload with useOptimisticLocking = true, which will enforce version checks during deletion and improve data integrity.

We will refactor the tests to add coverage on both current and new behavior. This approach allows us to introduce the feature in a backward-compatible manner, giving users the choice to adopt the new behavior at their discretion.

We look forward to your feedback on this approach.

Thanks anasatirbasa@ for the new version , will take a look at it in between this week

[joviegas]

Hello @joviegas, From this standpoint indeed it would be a breaking change. To address the potential breaking change and ensure full backward compatibility while introducing optimistic locking support, we propose the addition of a new overload for the addDeleteItem API:

* Current method signature (no Optimistic Locking support):
  `public <T> Builder addDeleteItem(MappedTableResource<T> mappedTableResource, T keyItem)`

* Proposed overload (with Optimistic Locking support):
  `public <T> Builder addDeleteItem(MappedTableResource<T> mappedTableResource, T keyItem, Boolean useOptimisticLocking)`

The current method will internally delegate to the new method using useOptimisticLocking = false, thereby maintaining the existing "delete regardless of version" behavior without introducing any breaking change. Developers who opt in to optimistic locking can explicitly call the new overload with useOptimisticLocking = true, which will enforce version checks during deletion and improve data integrity.

We will refactor the tests to add coverage on both current and new behavior. This approach allows us to introduce the feature in a backward-compatible manner, giving users the choice to adopt the new behavior at their discretion.

We look forward to your feedback on this approach.

Thanks anasatirbasa@ for the new version , will take a look at it in between this week