Skip to content

Adds operation name labels for operations to identify calling op when required #2846

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Nov 19, 2021

Conversation

cenedhryn
Copy link
Contributor

Motivation and Context

Adding these labels make it possible for the client to distinguish between different operations which is useful for the extensions framework.

Description

  • Added the label 'operationType' to all operations
  • Added operationType to the DynamoDbExtensionContext.BeforeWrite interface (the read framework isn't as tied to a specific operation and at this point in time doesn't require it nor is it easy to retrofit)

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 read the README document
  • I have added tests to cover my changes
  • All new and existing tests passed
  • A short description of the change has been added to the CHANGELOG
  • 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

@cenedhryn cenedhryn requested a review from a team as a code owner November 16, 2021 01:03
@cenedhryn cenedhryn requested a review from zoewangg November 16, 2021 23:41

@SdkInternalApi
public enum OperationType {
ANY("Any"), //unknown value
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should it be UNKNOWN_TO_SDK_VERSION(null); to be consistent with the service enum?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds better, lm check that out.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe just UNKNOWN? Because this is internal, why would we even need an UNKNOWN value? Can't we just always specify it for our operations?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't always know the operation in all code paths flowing through an operation. Especially on the read path, we make transforms and use extensions without coming directly from an operation. An example is the readAndTransform..Item operations in EnhancedClientUtils.
We could use null instead, which I don't prefer but I don't feel strongly about it.

@@ -96,6 +107,7 @@ public int hashCode() {
result = 31 * result + (operationContext != null ? operationContext.hashCode() : 0);
result = 31 * result + (tableMetadata != null ? tableMetadata.hashCode() : 0);
result = 31 * result + (tableSchema != null ? tableSchema.hashCode() : 0);
result = 31 * result + (operationType != null ? operationType.hashCode() : 0);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we have equals hashcode test? If not, can we add one using equalsVerifier?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good suggestion!

@cenedhryn cenedhryn force-pushed the salande/operation-labels branch 3 times, most recently from 19bb922 to 6bd013d Compare November 17, 2021 22:43
@cenedhryn cenedhryn force-pushed the salande/operation-labels branch from 6bd013d to 4fd7f03 Compare November 18, 2021 19:37
@sonarqubecloud
Copy link

SonarCloud Quality Gate failed.    Quality Gate failed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

71.2% 71.2% Coverage
0.0% 0.0% Duplication

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants