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

validate() rejects documented aggregate example before global mappings and aliases are resolved

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

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

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

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
72/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
python, rust
領域
backend, testing-qa

調査の方向性

src/validate.rs から始め、そのレイヤーマッピングの準備処理を src/execute/mod.rs の実行パスと比較してください。特に resolve_aesthetic_aliases() に注目します。再現用として doc/syntax/layer/type/range.qmd に記載されたクエリを使用してください。完了の条件は、クエリがエラーなしで検証され、検証と実行が一致し、実際にマッピングされていない集約ターゲットが回帰テストによって引き続き失敗することです。

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

説明

Summary

At v0.4.1, validate() rejects the documented aggregate range example even though the same query executes and renders successfully.

This creates a validation/execution parity problem for integrations that call validate() before execute(): a renderable chart is suppressed with:

Layer 1: aggregate target 'x' is not mapped on this layer

The example is currently documented in doc/syntax/layer/type/range.qmd.

Tested against tag v0.4.1, commit 6fcb07fd7ba40039c61b839c9979e0cad3bceea5.

Minimal reproduction

This uses the Python bindings pinned to core ggsql = "=0.4.1", but the failing behavior comes from the core ggsql::validate path.

import ggsql
import pyarrow as pa

query = """SELECT * FROM airquality
VISUALISE Date AS x, Temp AS ymin, Temp AS ymax, Temp AS color
DRAW range
  REMAPPING aggregate AS linewidth
  SETTING aggregate => (
    'x:first',
    'ymin:first', 'ymin:min',
    'ymax:last', 'ymax:max',
    'color:diff'
  ), hinge => null
  PARTITION BY Week
SCALE linewidth TO (5, 1)
SCALE BINNED color TO ('steelblue', 'firebrick')
  SETTING breaks => (-20, 0, 20)"""

reader = ggsql.DuckDBReader("duckdb://memory")
reader.register(
    "airquality",
    pa.table(
        {
            "Date": [
                "1973-05-01",
                "1973-05-02",
                "1973-05-08",
                "1973-05-09",
            ],
            "Temp": [67, 72, 68, 75],
            "Week": [18, 18, 19, 19],
        }
    ),
)

validated = ggsql.validate(query)
print(validated.valid())
print(validated.errors())

spec = reader.execute(query)
rendered = ggsql.VegaLiteWriter().render(spec)
print(len(rendered))

Actual output:

False
[{'message': "Layer 1: aggregate target 'x' is not mapped on this layer", 'location': None}]
6758

Expected:

  • validated.valid() is True
  • validated.errors() is empty
  • execution continues to produce the Vega-Lite spec

Root cause

The static validation path and execution path prepare layer mappings differently.

In src/validate.rs:

  1. The explicit mappings from VISUALISE ... live in plot.global_mappings.
  2. Validation clones the layer and merges those global mappings into merged.
  3. merged is used only for validate_mapping().
  4. validate_aggregate_setting() is then called on the original layer, whose mappings do not contain x, ymin, ymax, or color.

Consequently, resolve_aggregate_targets() cannot resolve the first target, x, and emits the error.

There is a second parity requirement in this particular documented example: color:diff targets an aesthetic alias. The execution path first merges globals and then runs resolve_aesthetic_aliases(), turning color into the concrete aesthetic supported by range (here stroke). The standalone validation path does not mirror this alias-resolution step.

This explains both observations:

  • static validation fails before execution;
  • execution succeeds because it has already merged global mappings and resolved aliases before the aggregate stat runs.

Proposed fix

Make standalone validation use the same effective layer mappings that execution uses before validating aggregate targets:

  1. Clone the layer.
  2. Merge applicable plot.global_mappings, preserving layer precedence and annotation behavior.
  3. Resolve aesthetic aliases on that effective layer according to the geom's supported aesthetics.
  4. Use the effective layer for both:
    • validate_mapping()
    • validate_aggregate_setting()

Ideally, factor the merge/alias preparation into a shared helper so validation and execution cannot drift again.

Simply replacing:

layer.validate_aggregate_setting(...)

with:

merged.validate_aggregate_setting(...)

would fix the first x failure, but is not sufficient for the full documented query unless the color alias is also resolved to stroke/ fill as appropriate for the geom.

For wildcard mappings, where standalone validation lacks schema information, aggregate syntax/vocabulary/recycling can still be checked, while target-resolution checks may need to be deferred until effective mappings are knowable.

Suggested regression coverage

  • The complete documented range query above returns valid() == true.
  • Global x/ymin/ymax aggregate targets validate.
  • Global color plus color:diff validates for a geom supporting the corresponding concrete alias target.
  • A genuinely unmapped aggregate target remains invalid.
  • Validation and execution agree for this query.
主要言語
Rust
スター
562
フォーク
31
平均マージ
2日 7時間
マージ済み PR（30日）
22

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

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

posit-dev/ggsql のほかの issue

posit-dev/ggsql の issue をすべて見る

似ている issue

Rust の issue をもっと見る

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

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