4paradigm / 4paradigm/OpenMLDB

lag correctness: wrong result used as parameter of other udaf

オープン
#3,299 コメント 1 件 リアクション 0 件 担当者 1 名 @aceforeverd が担当を希望しています GitHub で見る
bug execute-engine udf
主要言語
C++
スター
1.7k
フォーク
331
平均マージ
12日 12時間
マージ済み PR(30日)
1

説明

```yaml
- id: 66
sql: |
select
idx,
sum_where(val, val > lag(val, 1)) over w as out,
from t1
window w as (
partition by gp order by ts
rows_range between 10s preceding and 1s preceding
)
inputs:
- name: t1
columns: ["idx int", "gp int", "val int", "ts timestamp"]
indexs: ['idx:gp:ts']
data: |
100, 1, 1, 1000
200, 1, 2, 2000
300, 1, 1, 3000
400, 1, 2, 4000
expect:
columns:
- idx int
- out int32
order: idx
data: |
100, NULL
200, NULL
300, NULL
400, 2
```

`sum_where` and `lag` compute over the same history window [10s - 1s] , however does not meet the specification for `lag` (**always evaluated based on current row**).

コントリビューションガイド

コントリビューションガイドを開く

調査の方向性

The issue is about the lag function within a window in OpenMLDB, a C++ database for machine learning. The test case in the issue body shows the SQL query and expected output. Investigate the window function evaluation logic, likely in the SQL engine or UDAF implementation. Look for where lag is computed relative to the current row versus the window frame. Running the provided test will show the discrepancy. The fix involves ensuring lag uses the correct row context within the window.

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

評価

技術スタック
sql
領域
databases, machine-learning
issue の種類
バグ
難易度
4/5
見積もり時間
3〜5日
活発さ
停滞
明瞭さ
おおむね明確
初心者へのやさしさ
35/100

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

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