[Feature] Access table data with the temporary credentials issued by the REST catalog

Open
#369 0 comments 0 reactions 1 assignee View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
30/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
cpp
Domain
api, database

Research direction

Start by tracing Catalog::GetTableFileSystem, ReadContextBuilder, ScanContextBuilder, WriteContextBuilder, and CredentialProviderFactory::Get to understand the existing catalog and file-system extension points. Done means data-token.enabled remains backward-compatible, table credentials refresh independently before expiry, the builder and provider APIs work, and static built-in file-system credentials remain unchanged.

Written by the indexing model from the issue text.

Description

enhancement

Search before asking

  • I searched in the issues and found nothing similar.

Motivation

The C++ REST catalog can only read and write table data with the static credentials configured in the catalog options (fs.oss.accessKeyId and friends). A REST catalog that issues per-table temporary credentials (data tokens, e.g. DLF) has no way to have those credentials used for that table's data IO, and no way to keep them fresh before they expire. Callers that bring their own FileSystem also have no supported abstraction for sourcing credentials that expire.

Solution

Add data-token support to the REST catalog: when data-token.enabled=true, the catalog loads a table's temporary credentials and serves a refreshing FileSystem for that table through Catalog::GetTableFileSystem(identifier). ReadContextBuilder, ScanContextBuilder and WriteContextBuilder gain WithCatalog(catalog, identifier) so the table's schema and file system are resolved from the catalog in one call. The credentials are cached and reloaded before expiry by rebuilding the delegate file system keyed by the issued token, so a rotation of one table's credentials does not disturb the others.

Also add a generic CredentialProvider + CredentialProviderFactory extension point: a caller that brings its own FileSystem builds a provider with CredentialProviderFactory::Get and consults GetCredentials() at each access, then passes that file system in through Catalog::Create or a builder's WithFileSystem. The built-in file systems (oss, s3, local, jindo) keep signing with the static credentials of their own options.

Anything else?

data-token.enabled defaults to false, and the new API is additive, so the change is backward compatible.

Are you willing to submit a PR?

  • I'm willing to submit a PR!
Dominant language
C++
Stars
65
Forks
29
Avg merge
2d 30m
Merged PRs (30d)
77

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from apache/paimon-cpp

All issues in apache/paimon-cpp

Similar issues

More C++ issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.