Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
  • Quelque chose ne va pas ?
#271 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
46/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
python
Domaine
backend

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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)

Langage dominant
Python
Étoiles
142
Forks
19
Merge moyen
1 j 9 h
PR mergées (30 j)
9

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de xqlsystems/xarray-sql

Toutes les issues de xqlsystems/xarray-sql

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.