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

A view keeps reading a table after it is replaced: DataFusion binds views at creation

Abierto
  • ¿Algo no está bien?
#271 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
46/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
python
Área
backend

Línea de trabajo

Start by reading the Context table registration and deregistration behavior and the benchmark demo in benchmarks/ml referenced in the report. The issue offers documentation, a warning or refusal, or an upstream DataFusion report as possible directions, so first determine which outcome the maintainers want. Done means the chosen behavior is handled and the stale-view example no longer surprises users.

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

Descripción

On a Context, a view keeps reading the table it was created over, even after a new Dataset is registered under the same name. It returns the old rows without an error.

import numpy as np
import xarray as xr
import xarray_sql as xql

ctx = xql.Context()
ctx.from_dataset("t", xr.Dataset({"x": ("i", np.array([1.0]))}, coords={"i": [0]}))
ctx.sql("CREATE VIEW v AS SELECT x FROM t")

ctx.deregister_table("t")
ctx.from_dataset("t", xr.Dataset({"x": ("i", np.array([2.0]))}, coords={"i": [0]}))

print("table:", ctx.sql("SELECT x FROM t").to_pydict())  # {'x': [2.0]}
print("view: ", ctx.sql("SELECT x FROM v").to_pydict())  # {'x': [1.0]}: the old table

DataFusion 54.0.0, xarray-sql main. The same happens on a plain DataFusion SessionContext with register_record_batches, so the behavior is DataFusion's: CREATE VIEW stores a logical plan whose table scans hold the table providers that existed when the view was created.

Why it's a surprise:

  • DuckDB (1.5.5) resolves a view's tables by name when the view is queried, so the same steps, with xql.register, return the new rows.
  • PostgreSQL also binds a view to its tables when the view is created, but it refuses to drop a table that a view depends on unless you DROP … CASCADE. So it never returns stale rows.
  • DataFusion binds early and also allows the drop, so the view silently reads data that is no longer registered.

Where it bites: any loop that replaces a Dataset under a fixed name and reads it through a view. Examples are a training loop that re-registers its parameters each step, or a pipeline that swaps in each day's data. I hit it while writing the GPT demo in benchmarks/ml (#269) as a model view plus a loss. The demo works around it by recreating the view after each re-registration.

Possible directions:

  • Document it in the limitations page.
  • Have Context warn, or refuse, when deregister_table or from_dataset replaces a table that a view reads.
  • Report it upstream to DataFusion, if late binding or a dependency check would be welcome there. I didn't find an existing issue in apache/datafusion.

🌀 Claude (ML demos, xarray-sql)

Lenguaje dominante
Python
Estrellas
142
Forks
19
Merge medio
1 d 9 h
PR fusionados (30 d)
9

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 xqlsystems/xarray-sql

Todos los issues de xqlsystems/xarray-sql

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.