Skip to content

add support to set a prefix for the S3 key #118

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 1 commit into from
Sep 27, 2023

Conversation

evangilo
Copy link

*Issue #7 *

Description of changes:

  • This PR is adding an new attribute (s3KeyPrefix) for the ExtendedClientConfiguration class that will be used to compose the s3 key.
  • When the s3KeyPrefix is not null or empty, the S3 key object will use this attribute as prefix of the key. For example, if the s3KeyPrefix is queue-name/, the S3 key will be something like queue-name/676468c5-671f-4471-b9f6-fc5b0a5ab7de.
  • To keep the current behavior, the method payloadStore.storeOriginalPayload(messageContentStr, s3Key) will be used only if the s3KeyPrefix is not blank.

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

@@ -32,6 +33,7 @@ public class ExtendedClientConfiguration extends PayloadStorageConfiguration {
private boolean cleanupS3Payload = true;
private boolean useLegacyReservedAttributeName = true;
private boolean ignorePayloadNotFound = false;
private String s3KeyPrefix;
Copy link
Contributor

@ziyanli-amazon ziyanli-amazon Sep 26, 2023

Choose a reason for hiding this comment

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

Do you think we should consider checking the validness of the the s3KeyPrefix? e.g.

  1. The key name must be between 1 and 1024 bytes in length.
  2. some special characters may not be allowed or may have restrictions. For example, AWS S3 recommends avoiding characters like '/', '', and '@' because they can have special meanings in certain contexts.
  3. While you can use periods (".") in key names, you should avoid having a key name that starts with a period. Some tools and applications may not handle such key names well.
  4. AWS S3 has some reserved words that you should avoid using as key names, such as '.' and '..'.

Copy link
Author

Choose a reason for hiding this comment

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

I think we can add these validations. However, the / character is the only one I think we should allow because the AWS console will show the objects like a SO directory, which makes it easier to see messages of a specific queue or use case.

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes, i think allowing / should be fine. Originally the s3 recommended to not use it is due to performance drawback.

Copy link
Author

Choose a reason for hiding this comment

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

Do you think for this feature make sense allow only characters that matches with the regex [a-zA-Z0-9-_\/\.]? According to the S3 doc there many characters that we should avoid or requires special handling, and I think it should not be responsability of the amazon-sqs-java-extended-client lib handle this.

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes, taking every single corner case into consideration jumps out of the scope of this PR. I like your suggestion. One minor comment to that regex pattern is that
the hyphen is treated literally, which might be confusing for others. Consider escaping it or placing at the start or end of the string.
[a-zA-Z0-9\-\_\/\.]

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.

2 participants