Add missing metadata about storage objects to google-cloud-storage api #2058
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Keeping up to date with alpakka
lastScaleTime: "2019-11-12T12:11:46Z"
lastScaleTime: "2019-11-12T12:11:46Z"
GCS StorageObjectJson JsonFormat
…l ad next, haven't updated Formats
seglo
changed the title
|
@DanieleSassoli Everything looks good to me. Thanks a lot for the contribution and your patience throughout the review process! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Purpose
The intent of this PR is to be able to retrieve all the metadata about storage objects via the alpakka api.
Background Context
I'm writing an interface that should enable me to treat Sftp, Ftps, S3 and GCS files in the same way, I noticed that I could get information around when the document was last modified for Sftp and Ftps(still haven't got round to S3) but not for GCS, so thought I'd add it in.
I recreated this PR as substitute of #2009 as that was created of my master and that made it more difficult for people to contribute to it. Hopefully opening it from a branch should enable more collaboration.