Skip to content

feat(io): expose FileIO properties#14

Open
smaheshwar-pltr wants to merge 2 commits into
mainfrom
rest-fileio-properties
Open

feat(io): expose FileIO properties#14
smaheshwar-pltr wants to merge 2 commits into
mainfrom
rest-fileio-properties

Conversation

@smaheshwar-pltr

@smaheshwar-pltr smaheshwar-pltr commented Jun 27, 2026

Copy link
Copy Markdown
Owner

What

Add FileIO::properties(), returning the FileIO's configuration by const reference. The default returns an empty map; ArrowS3FileIO returns the properties it was configured with.

Why

An engine that performs its own I/O needs to read the resolved configuration off a loaded table's FileIO. Every other Iceberg implementation exposes this as a flat property map:

Scope / notes

  • Returns the FileIO's configuration (the config a table was loaded with). REST servers typically return vended credentials in that config, so they are surfaced here — exactly what Trino consumes.
  • Structured REST storage-credentials installed via SupportsStorageCredentials are a separate channel used for per-prefix routing and are not included, matching Java (whose FileIO.properties() likewise excludes them).
  • Additive: the new virtual carries a default ({}). Note it adds a method to the exported FileIO vtable.

Comment on lines +218 to +219
std::unordered_map<std::string, std::string> PropertiesForLocation(
std::string_view location) const override;

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't get this - what is the precedent for properties just per-location? Look at the prior PR - I wrote PR description + maybe comments citing sources of how different implementations provide properties to engines, did we get inspiration from one of those? Or if not why are we different from the other Iceberg implementations? Quite confused here

@smaheshwar-pltr
smaheshwar-pltr force-pushed the rest-fileio-properties branch from fc46f62 to 13a013b Compare June 27, 2026 23:21
return *best;
}

std::unordered_map<std::string, std::string> ArrowS3FileIO::properties() const {

@smaheshwar-pltr smaheshwar-pltr Jun 27, 2026

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Exposing the FileIO's configuration as a flat map is how every other implementation surfaces it to engines:

Real REST servers return vended credentials in a table's config, so they appear here; structured storage-credentials stay on the separate SupportsStorageCredentials channel, as in Java.

@smaheshwar-pltr
smaheshwar-pltr force-pushed the rest-fileio-properties branch from 13a013b to fe44eb3 Compare June 28, 2026 00:03
Add FileIO::properties(), returning the FileIO's configuration by const
reference. The default returns an empty map; ArrowS3FileIO returns the
properties it was configured with.

This lets an engine that performs its own I/O read the resolved configuration
of a table's FileIO, matching the property surface other Iceberg
implementations expose (Java FileIO.properties(), Rust config().props(),
Python table.io.properties; Trino reads baseTable.io().properties()). Vended
credentials returned in a table's config are part of that configuration and
are surfaced here; structured storage-credentials remain on the separate
SupportsStorageCredentials channel, as in Java.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@smaheshwar-pltr
smaheshwar-pltr force-pushed the rest-fileio-properties branch from fe44eb3 to 20f9c65 Compare June 28, 2026 00:05
@smaheshwar-pltr smaheshwar-pltr changed the title feat(io): expose resolved FileIO properties for a location feat(io): expose FileIO properties Jul 9, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant