Relevant Issue: https://sagebionetworks.jira.com/browse/PLFM-4253
StorageLocationSettings are immutable and thus can be cached client side. The information in these will therefore not be repeated in the new implementations of UploadDestination and FileHandle.The keyPath in ClientDelegatedS3UploadDestination is client generated:/<<UUID>>
keyPrefixUUID is a new UUID generated by the backend every time a ExternalObjectStoreUploadDestination is requested.
The key in ClientDelegatedS3FIleHandleExternalObjectStorageFileHandle, once uploaded will be <<UUID>>keyPrefixUUID/fileName.
The Interfaces exist for future comparability in case we need to add other client reliant storage solutions
New API
...
New API
The clients are responsible for creating FileHandles after upload has completed since Synapse does not have access to the new storage location
With the changes to the hierarchy of FileHandle, the POST /externalFileHandle service will be made generic to allow all implementations of ExternalFileHandleInterface
| Action | URI | Method | Request Body | Response Body |
|---|---|---|---|---|
| Creates a ClientDelegatedS3FileHandle. Its storageLocationId must match that of a ClientDelegatedS3StorageLocationSettingany instance of an ExternalFileHandleInterface | /externalFileHandle | POST | ClientDelegatedS3FileHandle | ClientDelegatedS3FIleHandle |
The backend only stores this information. I cannot perform many validity checks because the Synapse backend does not have access to the bucket. The only check it could do is ensure that the storagelocationid in the FileHandle is that of a ClientDelegatedS3StorageLocation
Unanswered questions/other thoughts
There's probably a better name for these classes.
Should we also make ExternalFileHandle and ExternalUploadDestination subclasses of ClientDelegatedFileHandleInterface and ClientDelegatedUploadDestinationInterface, respectively?
...
| ExternalFileHandleInterface | ExternalFileHandleInterface |