`SELECT *` fails after a column is added until the next write to the table
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
- 58/100
Línea de trabajo
Start by reproducing the query after the schema-only column addition, then read crates/datafusion/src/table/mod.rs at the provider declarations and iceberg-rust's TableScanBuilder::build, which binds scans to the snapshot schema. Done means the fresh provider can run SELECT * and return the existing value with NULL for the newly added column without a new table write.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Describe the bug
IcebergTableProvider and IcebergStaticTableProvider::try_new_from_table declare the table's current schema (table/mod.rs#L94-L97, table/mod.rs#L258-L262). iceberg-rust's scan binds the projection and filters to the schema of the snapshot it reads instead: TableScanBuilder::build uses snapshot.schema(...). After a schema change that has no snapshot of its own, the provider declares columns the scan can't find.
To Reproduce
- Create
t(a INT NOT NULL)and insert one row. - Add an optional column
c STRING, for example withTransaction::update_schema().add_column(AddColumn::optional("c", ...))or withALTER TABLE ... ADD COLUMNfrom Spark. Don't write any new data. - Build a fresh provider and run
SELECT * FROM t:
DataInvalid => Column c not found in table. Schema: table {
1: a: required int
}
Expected behavior
The query returns a = 1, c = NULL.
Additional context
The root cause is the iceberg-rust scan behavior tracked in apache/iceberg-rust#2565 and apache/iceberg-rust#2905. Until that's fixed upstream, this crate could declare the scanned snapshot's schema, or fill columns missing from it with nulls.
- Lenguaje dominante
- Rust
- Estrellas
- 33
- Forks
- 34
- Merge medio
- 4 d 14 h
- PR fusionados (30 d)
- 10
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de apache/datafusion-iceberg
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
apache/datafusion-iceberg#100 · 2 comentarios ·
Los mantenedores suelen responder en 1 día
-
Dificultad 4/5 3-5 días Aptitud para principiantes 55/100
apache/datafusion-iceberg#101 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
apache/datafusion-iceberg#85 · 1 comentario · 5 reacciones ·
Los mantenedores suelen responder en 1 día
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
apache/datafusion-iceberg#84 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
apache/datafusion-iceberg#75 ·
Los mantenedores suelen responder en 1 día
Todos los issues de apache/datafusion-iceberg
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
cloudflare/workers-rs#1130 ·
Los mantenedores suelen responder en 11 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 69/100
vfarcic/dot-agent-deck#2160 · 2 comentarios ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
RustCrypto/utils#1597 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Los mantenedores suelen responder en 1 día