validate() rejects documented aggregate example before global mappings and aliases are resolved
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 72/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Đặc tả rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Lĩnh vực
- backend, testing-qa
Hướng nghiên cứu
Bắt đầu trong src/validate.rs và so sánh phần chuẩn bị ánh xạ layer của nó với đường dẫn thực thi trong src/execute/mod.rs, đặc biệt là resolve_aesthetic_aliases(). Sử dụng truy vấn được ghi trong doc/syntax/layer/type/range.qmd để tái hiện. Được xem là hoàn tất khi truy vấn được xác thực mà không có lỗi, quá trình xác thực và thực thi thống nhất với nhau, và các đích aggregate thực sự chưa được ánh xạ vẫn thất bại thông qua coverage hồi quy.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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()isTruevalidated.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:
- The explicit mappings from
VISUALISE ...live inplot.global_mappings. - Validation clones the layer and merges those global mappings into
merged. mergedis used only forvalidate_mapping().validate_aggregate_setting()is then called on the originallayer, whose mappings do not containx,ymin,ymax, orcolor.
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:
- Clone the layer.
- Merge applicable
plot.global_mappings, preserving layer precedence and annotation behavior. - Resolve aesthetic aliases on that effective layer according to the geom's supported aesthetics.
- 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/ymaxaggregate targets validate. - Global
colorpluscolor:diffvalidates for a geom supporting the corresponding concrete alias target. - A genuinely unmapped aggregate target remains invalid.
- Validation and execution agree for this query.
- Ngôn ngữ chính
- Rust
- Star
- 562
- Fork
- 31
- Merge trung bình
- 2 ngày 7 giờ
- Pull request đã merge (30 ngày)
- 22
Chuẩn bị môi trường
Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của posit-dev/ggsql
-
Rename CLAUDE.md to AGENTS.mdĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
posit-dev/ggsql#565 · 2 reaction ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Update the positron dep for the extension to 0.2.9Có thể đã có người làm @thomasp85 đã nhận 13 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
Maintainer thường phản hồi trong vòng 1 ngày
-
writer
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
Maintainer thường phản hồi trong vòng 1 ngày
-
plot building
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 1 ngày
-
bug plot building
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của posit-dev/ggsql
Issue tương tự
-
C-bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
rust-lang/rust-analyzer#23501 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
Maintainer thường phản hồi trong vòng 1 ngày
-
[Bug]: Web chat input doesn't regain focus after a reply finishesCó thể đã có người làm @GaijinSystems đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
zeroclaw-labs/zeroclaw#11658 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
good first issue help wanted
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
bytecodealliance/wasm-tools#2768 ·
Maintainer thường phản hồi trong vòng 1 ngày