NIFI-14303 Additional metadata attributes in ListGoogleDrive

[turcsanyip]

Introduced optionally configurable metadata attributes in ListGoogleDrive Added drive.created.time and drive.modified.time in List/Fetch/PutGoogleDrive Fixed drive.timestamp in Fetch/PutGoogleDrive

Summary

NIFI-14303

Tracking

Please complete the following tracking steps prior to pull request creation.

Issue Tracking

• Apache NiFi Jira issue created

Pull Request Tracking

• Pull Request title starts with Apache NiFi Jira issue number, such as NIFI-00000
• Pull Request commit message starts with Apache NiFi Jira issue number, as such NIFI-00000

Pull Request Formatting

• Pull Request based on current revision of the main branch
• Pull Request refers to a feature branch with one commit containing changes

Verification

Please indicate the verification steps performed prior to pull request creation.

Build

• Build completed using mvn clean install -P contrib-check
  • JDK 21

Licensing

• New dependencies are compatible with the Apache License 2.0 according to the License Policy
• New dependencies are documented in applicable LICENSE and NOTICE files

Documentation

• Documentation formatting appears as expected in rendered files

[exceptionfactory]

Thanks for working on these improvements to provide additional metadata from Google Drive @turcsanyip.

Including the metadata seems helpful, but I'm not sure about making a configurable property for which attributes should be included. It seems simpler to always include the metadata. Is there a particular reason for providing the fine-grained level of control over the output?

I'm also wondering about the Folder Separator property, as it seems potentially confusing based on the description. It sounds like it requires some background knowledge of what will be listed, which seems like a dangerous assumption for continuous flows. Instead of making this configurable, it seems that a better approach would be some type of encoding strategy. Using URL encoding seems like the most obvious choice, which would support a standard / separator, and encode that character when it is part of file or folder names. There may be other options, but that is one that comes to mind.

[turcsanyip]

@exceptionfactory Created new PR with new attributes statically added and URL encoded folder names: #9779
Closing this PR.