Skip to content

feat: add ResolveAttribute #412

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 7 commits into from
Sep 13, 2023
Merged

feat: add ResolveAttribute #412

merged 7 commits into from
Sep 13, 2023

Conversation

ajewellamz
Copy link
Contributor

Issue #, if available:

Description of changes:

Add ResolveAttribute
Also change build to preferentially use MavenLocal over MavenCentral

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

@ajewellamz ajewellamz requested a review from a team as a code owner September 13, 2023 13:51
Copy link
Contributor

@lucasmcdonald3 lucasmcdonald3 left a comment

Choose a reason for hiding this comment

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

Can we add a similar demonstration for the compound beacon example?

We can validate that resolveOutput.CompoundBeacons contains the expected value.

@@ -417,6 +424,21 @@ public static void PutItemQueryItemWithVirtualBeacon(String ddbTableName, String
// Validate the item has the expected attributes
assert returnedItem.get("state").s().equals("CA");
assert returnedItem.get("hasTestResult").bool().equals(true);

// 14. Check virtual field values directly
Copy link
Contributor

Choose a reason for hiding this comment

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

Should this go immediately after we construct the item? Maybe line 357?
When I see this code located after my queries, I'm expecting that I need the result of some query to validate my beacon transforms. But I actually only need to construct the item. I think we can move this to immediately after we construct the item as a validation on our config and item up until that point.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I like it at the end, because it's something a customer wouldn't normally do.

I updated the comment to make that clearer.

Comment on lines 438 to 439
Map<String, String> vf = new HashMap<>();
assert resolveOutput.CompoundBeacons().equals(vf);
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
Map<String, String> vf = new HashMap<>();
assert resolveOutput.CompoundBeacons().equals(vf);
// We did not construct any compound beacons
assert resolveOutput.CompoundBeacons().isEmpty();
// Validate our virtual field is constructed as expected
Map<String, String> vf = new HashMap<>();

Comment on lines 267 to 271
final HashMap<String, AttributeValue> item = new HashMap<>();
item.put("work_id", AttributeValue.builder().s("9ce39272-8068-4efd-a211-cd162ad65d4c").build());
item.put("inspection_date", AttributeValue.builder().s("2023-06-13").build());
item.put("inspector_id_last4", AttributeValue.builder().s("5678").build());
item.put("unit", AttributeValue.builder().s("011899988199").build());
Copy link
Contributor

Choose a reason for hiding this comment

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

I somehow want to point this at the config on line ~296 so readers know where this is coming from. Maybe either

  • Refactor into one (e.g.) createHashmapForExampleItem function, call from both locations
  • Add a comment here "this is the same item config as in the PutAndQueryItemWithCompoundBeacon function"

.build();

final ResolveAttributesOutput resolveOutput = trans.ResolveAttributes(resolveInput);
Map<String, String> vf = new HashMap<>();
Copy link
Contributor

Choose a reason for hiding this comment

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

vf -> compoundBeacons or cbs?

Map<String, String> vf = new HashMap<>();

// VirtualFields is empty because we have no Virtual Fields configured
assert resolveOutput.VirtualFields().equals(vf);
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
assert resolveOutput.VirtualFields().equals(vf);
assert resolveOutput.VirtualFields().isEmpty();

Map<String, String> vf = new HashMap<>();

// CompoundBeacons is empty because we have no Compound Beacons configured
assert resolveOutput.CompoundBeacons().equals(vf);
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
assert resolveOutput.CompoundBeacons().equals(vf);
assert resolveOutput.CompoundBeacons().isEmpty();

Comment on lines 81 to 84
# Clear MPL from cache
# We have to do this because MakeFile does not do this yet. The MakeFile automatically builds and deploys dependencies
# instead it should be picking it up from Maven.
rm -rf ~/.m2/repository/software/amazon/cryptography/aws-cryptographic-material-providers
Copy link
Contributor

Choose a reason for hiding this comment

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

What is the result of this change, and why is it necessary for these changes? Does this mean we are now testing against the locally built version (what the submodule points to)?

Should we instead update the Makefile to include a build target that does not recursively build/locally deploy the MPL when building the DB-ESDK?

Copy link
Contributor

Choose a reason for hiding this comment

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

This change will make our local development simpler, as we can reason about always verifying/testing against the MPL submodule. This also allows us to develop feature branches in this repo against pending releases in the MPL, when no official release yet exists in Maven Central.

This is safe as long as we ensure at release time that we are testing against the MPL in Maven Central, and have some additional check to ensure that the commit of the submodule matches the commit that was released for the MPL version configured in the build.gradle.

Talking offline with @ajewellamz, we will remove this change from this PR for now, and reintroduce it once we have those additional mechanisms in place.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Reverted

Copy link
Contributor

Choose a reason for hiding this comment

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

It looks like our release script does test the staging artifact without a locally built MPL (https://github.com/aws/aws-database-encryption-sdk-dynamodb-java/blob/main/codebuild/staging/validate-staging.yml#L54-L57), so we just need to ensure that we have an additional check that the submodule matches the version in our build.gradle (This can start out as a manual check).

…namoDbEncryptionTransforms.smithy

Co-authored-by: Lucas McDonald <[email protected]>
@lucasmcdonald3
Copy link
Contributor

LGTM pending comments from @lavaleri .

@ajewellamz ajewellamz merged commit 26f3eba into main Sep 13, 2023
@ajewellamz ajewellamz deleted the resolve-atribute branch September 13, 2023 19:38
ajewellamz added a commit that referenced this pull request Nov 14, 2023
* feat: add ResolveAttribute
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