Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Support calendar-month/year (mo/y) intervals for Continuous Query EVERY and RANGE clauses

Đang mở
  • Có gì không ổn?
#18,428 9 bình luận 0 reaction 1 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

@DaZuiZui đang làm issue này rồi.

Từ ngày 10/8/2026.

Đánh giá

Issue này chưa được đánh giá.

Mô tả

good-first-issue New Feature

Is your feature request related to a problem?

IoTDB's Continuous Query (CQ) does not support calendar-month (or calendar-year) alignment for the EVERY execution interval and the RANGE time offsets. This makes it impossible to schedule a CQ that fires exactly at month boundaries — e.g. "run at the end of every month and aggregate over the whole natural month" — which is a common downsampling requirement. Because months have 28/29/30/31 days, the window length must be handled dynamically, so a fixed-day interval is not an adequate substitute.

Current behavior

Documentation

The CQ documentation states that every_interval, start_time_offset, and end_time_offset support only the units ns, us, ms, s, m, h, d, w — mo (month) and y (year) are not listed:

<every_interval> specifies the query execution time interval. We currently support the units of ns, us, ms, s, m, h, d, w ...

Source: https://iotdb.apache.org/UserGuide/latest/User-Manual/Database-Programming.html

Implementation

However, the implementation does not reject mo/y in these clauses — it silently accepts them and converts them to a fixed duration (1 month → 30 days, 1 year → 365 days):

  • iotdb-core/datanode/src/main/java/org/apache/iotdb/db/utils/DataNodeDateTimeUtils.java — the single-argument overload convertDurationStrToLong(String) is called with currentTime = -1, so the mo/month branch flattens to 30 * 86_400_000 ms and y/year to 365 * 86_400_000 ms.
  • The CQ parser uses exactly this overload for EVERY/RANGE: ASTVisitor.parseResampleClause(...) in iotdb-core/datanode/src/main/java/org/apache/iotdb/db/queryengine/plan/parser/ASTVisitor.java.
  • The scheduler then treats the result as a plain long and does pure integer arithmetic (executionTime += everyInterval, getFirstExecutionTime(...)) in iotdb-core/confignode/src/main/java/org/apache/iotdb/confignode/manager/cq/CQScheduleTask.java — there is no calendar logic at runtime.

As a result, EVERY 1mo does not mean "at the end of every calendar month"; it means "every fixed 30 days", which drifts relative to real month boundaries. This is arguably worse than a clean rejection, because the statement appears to be accepted but is silently mis-scheduled.

Note that GROUP BY(1mo) in the CQ body does work as a natural calendar month, because it goes through a different converter (constructTimeDuration, which keeps a separate monthDuration part and can be evaluated against the calendar). So within a single CQ the EVERY/RANGE cadence (fixed 30 days) and the GROUP BY window (natural month) can drift apart.

Desired behavior

Support mo/month and y/year as first-class units for the CQ EVERY interval and RANGE offsets, evaluated against the calendar (the way GROUP BY already handles months), so a CQ can be aligned to true month/year boundaries.

CREATE CONTINUOUS QUERY cq_monthly_spread
RESAMPLE EVERY 1mo RANGE 1mo
BEGIN
  SELECT max_value(s), min_value(s)
  INTO root.db.device(monthly_max, monthly_min)
  FROM root.db.device
  GROUP BY(1mo)
END

This should execute at each month boundary and aggregate over the just-finished natural month (correctly handling 28/29/30/31-day months).

Alternatives considered

  • External scheduler (e.g. cron at month-end) running a one-shot query — works today, but moves scheduling logic outside IoTDB and loses CQ's built-in result-sink semantics.
  • Daily CQ with EVERY 1d RANGE 31d + GROUP BY(1mo) — partially works, but the monthly result is recomputed daily and only "finalizes" after month-end; and RANGE 31d is still a fixed window rather than a true calendar month.

Additional context

As a smaller, complementary fix (or interim step), the silent 30/365-day flattening of mo/y in EVERY/RANGE could be turned into an explicit error, so that the runtime behavior matches the documentation and users are not misled into thinking EVERY 1mo produces a calendar-month cadence.

/ccraised by a user who wants month-end downsampling (spread = max − min over a natural month).

Ngôn ngữ chính
Java
Star
6.4k
Fork
1.2k
Merge trung bình
1 ngày 15 giờ
Pull request đã merge (30 ngày)
178

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. 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.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của apache/iotdb

Tất cả issue của apache/iotdb

Issue tương tự

Thêm issue về Java

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.