Skip to content
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

[Multitenant] BlobStore API refactoring #5282

Open
vttranlina opened this issue Sep 19, 2024 · 3 comments
Open

[Multitenant] BlobStore API refactoring #5282

vttranlina opened this issue Sep 19, 2024 · 3 comments

Comments

@vttranlina
Copy link
Member

vttranlina commented Sep 19, 2024

Epic: #5263

How

  1. Refactor BlobStore

Before proceeding with the refactor, we need to introduce the following classes:

  • Tenant
public record Tenant(String name) {
    public static Tenant from(Domain domain) {
        return new Tenant(domain.asString());
    }
    public String asString() {
        return name;
    }
}
  • Bucket
public record Bucket(BucketName bucketName, Optional<Tenant> tenant) {
    public static Bucket of(BucketName bucketName) {
        return new Bucket(bucketName, Optional.empty());
    }
}

For each method in BlobStore, we need to create a new API where the input argument changes from BucketName to Bucket.

Example:

  • Current: InputStream read(BucketName bucketName, BlobId blobId);
  • New API: InputStream read(Bucket bucket, BlobId blobId);
  • In the interface, modify the existing API as a default method. For example:
default InputStream read(BucketName bucketName, BlobId blobId) {
    return read(Bucket.of(bucketName), blobId);
}
  1. Refactor BlobStoreDAO
  • Apply a similar refactoring as in BlobStore, adapting the API to use the new Bucket class.
  1. Refactor the related class
  • BlobStore implementations:
    • CachedBlobStore
    • DeDuplicationBlobStore
    • MetricableBlobStore
    • PassThroughBlobStore
  • BlobStoreDAO implementations:
    • AESBlobStoreDAO, CassandraBlobStoreDAO, MemoryBlobStoreDAO: Consider whether to throw new UnsupportException? or try to adapt with current way (Optional[Tenant] = empty) ?
    • File multitenancy
    • S3BlobStoreDAO (will do in another ticket)
@Arsnael
Copy link
Member

Arsnael commented Sep 19, 2024

AESBlobStoreDAO, CassandraBlobStoreDAO, MemoryBlobStoreDAO: Consider whether to throw new UnsupportException? or try to adapt with current way (Optional[Tenant] = empty) ?

I personally think Optional[Tenant] = empty for now, until we do proper implementation? That should keep the current behavior then correct?

@quantranhong1999
Copy link
Member

apache#2485

@quantranhong1999 quantranhong1999 removed their assignment Nov 7, 2024
@quantranhong1999
Copy link
Member

I put this on hold.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants