Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Shared design for DataTree tables with duckdb-zarr: one schema per node

オープン
  • 何か問題がありますか？
#262 コメント 2 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
12/100
issue の種類
機能追加
明瞭さ
説明が足りない
活発さ
活発
技術スタック
python, sql
領域
data, databases

調査の方向性

This is an open design proposal, not a task with a defined change. Read the proposal and the linked #82 and xqlsystems/duckdb-zarr#52, then the existing default_table_name and resolve_table_names helpers the design reuses per node. The open questions (catalog-per-tree versus flat names, root node as default schema, table_names keys) need a maintainer decision in the thread before any code. Done means that decision is recorded, not that a patch exists.

索引モデルが issue の本文から書いたものです。

説明

duckdb-zarr is adding support for Zarr stores with nested groups, such as those written by xarray.DataTree.to_zarr(). We'd like both projects to turn the same store into the same tables, with the same names, so this issue proposes a shared design. It builds on #82.

The duckdb-zarr version is decision 8 in xqlsystems/duckdb-zarr#52 (design only, no code yet).

Proposal

  1. A table is one dimension group in one node. It's identified by (node path, dims). Arrays in different nodes never share a table, even when their dimension names match. This is the DataTree model: simulation/coarse and simulation/fine can both have foo(x, y) with different lengths of x.
  2. Tables inside a node are named with the existing rules. default_table_name ("_".join(dims) in dimension order, scalar for none) and resolve_table_names (overrides keyed by the dims tuple, case-insensitive collision check), applied per node.
  3. A node maps to a schema. Tree → catalog, node path → schema, dimension group → table:
    • The root node is the default schema: main in DuckDB, public in DataFusion.
    • A nested path is one quoted schema name: sim."simulation/fine".x_y.
    • In DataFusion this is a CatalogProvider whose SchemaProviders are the nodes, as suggested in #82.
  4. Coordinates are inherited like xarray. A node's tables include coordinates from its ancestors for dimensions the node shares with them, the same view dt["simulation/fine"].to_dataset() gives.
  5. Opening one node uses xarray's word. duckdb-zarr adds read_zarr(store, group := 'simulation/fine'), matching xr.open_zarr(store, group=...). With no group, only the root node is read.

Questions for xarray-sql

  • Does a catalog per tree and a schema per node fit the planned from_datatree API? Or would you rather have flat table names in one schema (for example simulation_fine__x_y)?
  • How should the root node look? Is it the default schema, or a schema named after the tree?
  • Should table_names overrides for a tree be keyed by (node_path, dims), with the per-node dims keys kept as they are?
  • Is anything in xarray-sql's pivot tied to one flat Dataset that would make inherited coordinates hard?

Why now

The immediate user is AnnData (xqlsystems/duckdb-zarr#40). An AnnData store is a tree: obs and var are nodes, and X, layers and obsm share their axes. The AnnData-specific parts come after this: naming its axes and decoding its categorical, nullable and sparse groups. Agreeing on the tree mapping first means both projects expose AnnData the same way.

主要言語
Python
スター
142
フォーク
19
平均マージ
1日 9時間
マージ済み PR（30日）
9

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

xqlsystems/xarray-sql のほかの issue

xqlsystems/xarray-sql の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。