-
Notifications
You must be signed in to change notification settings - Fork 16
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
Conversation
There was a problem hiding this 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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
Map<String, String> vf = new HashMap<>(); | ||
assert resolveOutput.CompoundBeacons().equals(vf); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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<>(); |
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()); |
There was a problem hiding this comment.
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<>(); |
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
assert resolveOutput.CompoundBeacons().equals(vf); | |
assert resolveOutput.CompoundBeacons().isEmpty(); |
.github/workflows/ci_test_java.yml
Outdated
# 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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reverted
There was a problem hiding this comment.
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).
DynamoDbEncryption/dafny/DynamoDbEncryptionTransforms/Model/DynamoDbEncryptionTransforms.smithy
Outdated
Show resolved
Hide resolved
…namoDbEncryptionTransforms.smithy Co-authored-by: Lucas McDonald <[email protected]>
LGTM pending comments from @lavaleri . |
* feat: add ResolveAttribute
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.