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

feat(logs): Add support for multiple parse and filter statements in QueryString #24022

Merged
merged 8 commits into from
Feb 18, 2023

Conversation

MikeJamesWhite
Copy link
Contributor

Currently, QueryString is limited to only allow a single line/statement to be provided for each query command. For some commands this makes sense (e.g. limit), but for parse and filter this can be limiting. Adding multiple lines for these commands is possible in the AWS console, so it makes sense for it to be supported in CDK too.

In this PR, I'm adding support for filter and parse to be provided as string or string[], and adding/modifying various utility methods to handle this ambiguity.

I left the existing tests the same to verify no breaking changes, and added a new test for the newly enabled behavior.


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

@gitpod-io
Copy link

gitpod-io bot commented Feb 6, 2023

@aws-cdk-automation aws-cdk-automation requested a review from a team February 6, 2023 01:16
@github-actions github-actions bot added p2 beginning-contributor [Pilot] contributed between 0-2 PRs to the CDK labels Feb 6, 2023
Copy link
Collaborator

@aws-cdk-automation aws-cdk-automation left a comment

Choose a reason for hiding this comment

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

The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.

@MikeJamesWhite MikeJamesWhite changed the title feat(aws-logs): Add support for multiple parse and filter statements in QueryString feat(logs): Add support for multiple parse and filter statements in QueryString Feb 6, 2023
@MikeJamesWhite
Copy link
Contributor Author

MikeJamesWhite commented Feb 6, 2023

I made the changes requested by the bot above, however I don't have the ability to run the integ tests on my side. Would it be possible for the reviewer to execute these? Asking based on this guidance from the contribution guidelines:

If you are working on a PR that requires an update to an integration test and you are unable to run the cdk-integ tool to perform a real deployment, please call this out on the pull request so a maintainer can run the tests for you

Nevermind, managed to get the integ tests to run.

@aws-cdk-automation aws-cdk-automation dismissed their stale review February 6, 2023 15:01

✅ Updated pull request passes all PRLinter validations. Dissmissing previous PRLinter review.

@TheRealAmazonKendra
Copy link
Contributor

@Mergifyio update

@mergify
Copy link
Contributor

mergify bot commented Feb 10, 2023

update

✅ Branch has been successfully updated

Copy link
Contributor

@TheRealAmazonKendra TheRealAmazonKendra left a comment

Choose a reason for hiding this comment

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

Thank you for your contribution! This looks great overall but there are a couple comments inline in regard to the types used.

*
* @default - no parse in QueryString
*/
readonly parse?: string;
readonly parse?: string | string[];
Copy link
Contributor

Choose a reason for hiding this comment

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

We can't use union types with jsii so this won't work/ Let's deprecate this prop and create a new on that's an optional string[]. Actually, can we also make this more strongly typed? If not, that's fine, but it would be nice to tighten the contract if we're deprecating props anyway.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hey @TheRealAmazonKendra -- I'm not the most familiar with typescript or CDK so just checking if I understand: by more strongly typed do you mean something like adding a specific "ParseStatement" type which has "inputAttribute", "parsePattern" and "outputAttributes" as members? I could do this to ensure the generated line is in the correct format, and validation could even be added to catch user errors early at build time (e.g. when number of "*" in the parsePattern != length of outputAttributes).

However, I'm not sure if this would be too heavyweight (I would have assumed so, even though I don't mind spending the time to add it in), so interested in your thoughts?

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 made the change to support string[] instead -- my feeling is that the above is too heavyweight anyway, but let me know :)

*
* @default - no filter in QueryString
*/
readonly filter?: string;
readonly filter?: string | string[];
Copy link
Contributor

Choose a reason for hiding this comment

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

Same comment as above.

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 think making this one more strongly typed may be difficult, but happy to look into it if you have any suggestions :) Either way I can do the update to ensure jsii plays nicely, but will wait for your reply first.

* @param statements one or more query statements for the specified command, or undefined
* @returns an array of the query string lines generated from the provided command and statements
*/
buildQueryLines(command: string, statements?: string[]): string[] {
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 be public? private? A function like noUndef was? This seems to be an internal-only thing that needs to hold no state, so I think it should be a function outside of the class

Copy link
Contributor Author

Choose a reason for hiding this comment

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

My feeling is that since it's irrelevant outside of the QueryString class, it should be a method of that class. That being said, I missed the private prefix so can definitely add that in.

}

return (typeof statements === 'string' ? [statements] : statements).map(
Copy link
Contributor

Choose a reason for hiding this comment

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

statements is typed as string[] | undefined, so typeof statements === 'string' should never work. If it does work, then we've got our type modeling wrong. Please remove this check and ensure that only string[]s are passed to this function.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Forgot to update this after making changes following the previous comments -- pushing a change now :)

@mergify mergify bot dismissed comcalvi’s stale review February 15, 2023 19:35

Pull request has been modified.

@MikeJamesWhite MikeJamesWhite requested review from comcalvi and removed request for TheRealAmazonKendra February 15, 2023 19:38
comcalvi
comcalvi previously approved these changes Feb 16, 2023
@mergify
Copy link
Contributor

mergify bot commented Feb 16, 2023

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

@mergify mergify bot dismissed comcalvi’s stale review February 18, 2023 06:33

Pull request has been modified.

@mergify
Copy link
Contributor

mergify bot commented Feb 18, 2023

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

@mergify mergify bot merged commit 75eb933 into aws:main Feb 18, 2023
@mergify
Copy link
Contributor

mergify bot commented Feb 18, 2023

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • CodeBuild project: AutoBuildv2Project1C6BFA3F-wQm2hXv2jqQv
  • Commit ID: 03e8ef0
  • Result: SUCCEEDED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
beginning-contributor [Pilot] contributed between 0-2 PRs to the CDK p2
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants