Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

StaticTableProvider can't be reconstructed in another process

Abierto
#3,017 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
55/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
rust

Línea de trabajo

Comienza en el crate iceberg-datafusion siguiendo el recorrido de IcebergStaticTableProvider, IcebergTableScan y la ruta del plan físico; después, compara las entradas de catálogo utilizadas por CatalogBuilder::load y iceberg-catalog-loader. El trabajo estará completo cuando la configuración de catálogo básica quede expuesta, se transmita a través de la planificación y el comportamiento existente permanezca sin cambios cuando esté ausente.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

enhancement
Is your feature request related to a problem or challenge?

IcebergStaticTableProvider holds a Table, which owns a live FileIO and is
bound to the catalog it was loaded from. Neither survives serialization.

That blocks distributed execution: engines like DataFusion Ballista plan on one
node and execute on others, so IcebergTableScan has to be shipped to workers
that then rebuild storage before they can read data files. The provider knows
which catalog it loaded from, but drops that information, leaving consumers no
way to identify the table well enough to rebuild it elsewhere.

The repo already has the shape needed: CatalogBuilder::load takes name and
props, and iceberg-catalog-loader selects a builder by type. That triple
just isn't recorded on the read path.

Describe the solution you'd like

Add IcebergCatalogConfig { type, name, props } to iceberg-datafusion: plain
data, no live connections, mirroring the loader's inputs. Let
IcebergStaticTableProvider record it and expose it alongside table_ident()
and snapshot_id(), and let IcebergTableScan carry it into the physical plan.

Together those are enough to rebuild the catalog, load the Table, and pin the
same snapshot. Nothing in the crate would connect using them; the config is an
Option defaulting to None, so existing behavior is unchanged.

Willingness to contribute

I can contribute to this feature independently

Lenguaje dominante
Rust
Estrellas
1.4k
Forks
574
Merge medio
1 d 20 h
PR fusionados (30 d)
65

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de apache/iceberg-rust

Todos los issues de apache/iceberg-rust

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.