The spec doesn't keep track of the manifest or position in the manifest
where a data file is stored because that information is determined by
writing a data file into a manifest. It's useful to keep track of that
information for writes, but it isn't necessarily correct by the time the
write commits so it is a hint only.

For server-side scan planning, I'm not sure that it makes sense to add this
to the REST protocol. It seems odd to me that a client that can read and
write metadata would use server-side planning. I typically think of the use
case for server-side scan planning as primarily supporting cases where the
client is either incapable of planning itself (like a simple client in a
new language) or not allowed to read metadata files for security reasons.
It is possible that server-side planning could be used in other cases, but
I wouldn't expect it to be used by writers. And if it were, I think it's
fine that the hints are not present.

Ryan

On Tue, Aug 12, 2025 at 11:46 AM Ma, Limin <l...@akamai.com.invalid> wrote:

> Hi All,
>
>
>
> /v1/{prefix}/namespaces/{namespace}/tables/{table}/plan
>
> Response:
>
> *{*
>
> *"file-scan-tasks"**: [*
>
> *    {*
>
>       *"data-file"**: {*
>
>         *"file-path"**: **"string"**,*
>
> *        ...*
>
> *       }*
>
> *    }]*
>
> *}*
>
>
>
>
>
> The spec does not indicate “data_file” has 'metadataLocation' property.
> But with Iceberg Vanilla local TableScan, DataFile (extends ContentFile)
> objects have ‘metadataLocation’ populated, which is used by
> MergingSnapshotProducer’s filterManager to efficiently identify relevant
> manifest files for filtering.
>
>
>
> Any reason why Rest spec does not support that or will it be considered
> for support in future versions?
>
>
>
> Thanks,
>
> Limin
>

Reply via email to