Skip to content
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

Add smithy-jmespath for parsing JMESPath #621

Merged
merged 5 commits into from
Nov 11, 2020
Merged

Add smithy-jmespath for parsing JMESPath #621

merged 5 commits into from
Nov 11, 2020

Conversation

mtdowling
Copy link
Member

We will be using JMESPath in things like waiters, so we need a JMESPath
parser that has no dependencies, exposes a rich AST that can be used in
code generation, and performs static analysis of expressions.

Issue #, if available:

Description of changes:

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

We will be using JMESPath in things like waiters, so we need a JMESPath
parser that has no dependencies, exposes a rich AST that can be used in
code generation, and performs static analysis of expressions.
Waiters are a client-side abstraction used to poll a resource until a
desired state is reached, or until it is determined that the resource
will never enter into the desired state.

Waiters have been available in AWS SDKs since around 2012, and are now
part of Smithy as an additional specification. Note that this PR relies
on smithy-jmespath.
This commit makes a few changes to waiters:

1. I removed and, or, and not. I couldn't think of a real use case for
   these as I was documenting them, so I am erring on the side of
   simplicity.
2. I removed the emptyArray comparator. This need more work to properly
   validate and specify it, and it can actually be acheived using a
   booleanEquals comparator by checking if a returned length of a value
   in JMESPath is equal to 0. No need for an extra comparator.
3. I added a new matcher named `inputOutput` that has two top level
   keys: input and output. This allows both input and output data to be
   queried *together* for successful operations, solving a longstanding
   use case we've had for things like making sure the number of
   autoscaling groups on input matches the number returned on output.
4. Given that and, or, and not was removed, there's no purpose for a
   standalone "input" matcher, particularly since there's now an
   "inputOutput" matcher.
@mtdowling mtdowling merged commit 83cceca into master Nov 11, 2020
@mtdowling mtdowling deleted the jmespath branch December 11, 2020 17:58
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