...
- Introduction of Google Cloud external storage locations makes additive changes necessaryJira Legacy server System JIRA serverId ba6fb084-9827-3160-8067-8ac7470f78b2 key PLFM-5604 - Need to add a new type - GoogleCloudFileHandle
- We can generate previews of Google Cloud files, but the existing PreviewFileHandle implements S3FileHandleInterface, requiring some sort of change.
- /wiki/spaces/SYNPY/pages/819855621 - We can consider taking take this opportunity to clear up confusion with this API
Attempt to make entirely additive changes to avoid making breaking API changes (especially for clients)- Fix up cruft and simplify design decisions
Changes
I am proposing the following changes:
- Introduction of three new interfaces
- PreviewFileHandleInterface - Defines which objects are preview file handles.
- GoogleCloudFileHandleInterface - Defines which objects represent file handles that exist in Google Cloud
- CloudProviderFileHandleInterface - Defines which objects represent file handles stored by a cloud provider (e.g. S3, Google Cloud, potentially others in the future)
- Introduction of two new classes:
- GoogleCloudFileHandle - A file handle that represents a file in Google Cloud (analogous to S3FileHandle)
- GoogleCloudPreviewFileHandle - A file handle that represents a preview of a GoogleCloudFileHandle (analogous to PreviewFileHandle)
Current Hierarchy
Proposed Hierarchy
Alternative Considerations
We could simply add a GoogleCloudFileHandleInterface that extends the FileHandle interface, but clients should rarely (if ever) be concerned whether a FileHandle is in S3 vs. Google Cloud (this can be contrasted with external file handles). This is a reason to introduce an interface that both S3FileHandle and GoogleCloudFileHandle implement.
PreviewFileHandle implements S3FileHandleInterface, which means we must do at least one of:
- Add a new GoogleCloudPreviewFileHandle class or
- Add a field to PreviewFileHandle that indicates if the file is in S3 or Google Cloud and break the hierarchy (remove implements S3FileHandleInterface)Would this be a breaking change for clients?Rename S3FileHandleInterface to CloudProviderFileHandleInterface
- Still defines bucket and key
- Add fields previewId and isPreview
- Add class GoogleCloudFileHandle (implements CloudProviderFileHandleInterface)
- Remove PreviewFileHandle
- PreviewFileHandles are just S3FileHandles or GoogleCloudFileHandles where isPreview is
true
- PreviewFileHandles are just S3FileHandles or GoogleCloudFileHandles where isPreview is
- Remove HasPreviewId
- The information necessary for locating and identifying previews moves to the CloudProviderFileHandleInterface class
- While ExternalFileHandle and ProxyFileHandle can have previews under the old tree, there are 0 previews of external files in production (as of 2019-07-22)
Current Hierarchy
Proposed Hierarchy
Additional Considerations
We can rename ExternalFileHandleInterface if we want to. One suggestion is OtherFileHandleInterface, since it seems to be a catch all for everything that doesn't fall under the other category.
Other naming suggestions are welcome.