Skip to content

Conversation

@JinqingKuang
Copy link
Contributor

@JinqingKuang JinqingKuang commented Oct 22, 2025

Description

Please briefly describe the code changes in this pull request.

Checklist

Please check the items in the checklist if applicable.

  • Is the user manual updated?
  • Are the test cases passed and automated?
  • Is there no significant decrease in test coverage?
@gemini-code-assist
Copy link
Contributor

Summary of Changes

Hello @JinqingKuang, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly enhances the stream processing engine by introducing support for sub-events within event window triggers. This feature allows for more sophisticated event detection by enabling a 'parent' event to be composed of multiple, distinct 'sub-events,' each with its own set of conditions. The changes involve updates to core data structures, event processing logic, and the SQL parsing mechanism to seamlessly integrate this new capability, providing richer and more granular event-driven insights.

Highlights

  • Sub-Event Support in Event Windows: Introduced the capability to define sub-events within an event window trigger, allowing the START WITH clause to accept a list of search conditions.
  • Data Structure Updates: Modified the SSTriggerRealtimeGroup structure to include fields like parentWindow, numSubWindows, and conditionIdx to manage the state of nested event windows.
  • Enhanced Event Notification: The streamBuildEventNotifyContent function now accepts additional parameters (condIdx, winIdx) to provide more detailed context in event notifications, indicating which sub-condition or window triggered the event.
  • Parsing Logic Refinement: Updated the SQL parser to recognize and process the new syntax for event windows with multiple start conditions, ensuring proper parsing and deployment of these complex triggers.
Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request introduces support for sub-events in event window triggers, which is a significant feature enhancement. The changes span across parsing, task deployment, and runtime logic. The use of a union in SSTriggerRealtimeGroup is a good optimization. However, I've identified a few areas where the implementation could be improved for clarity, maintainability, and robustness. My main concerns are around the complex loop control flow using i-- in stRealtimeGroupDoEventCheck, the potentially brittle logic for identifying parent windows in stRealtimeGroupGenCalcParams, and a semantic type mismatch in stRealtimeContextCalcExpr. Please see the detailed comments for suggestions on how to address these points.

@JinqingKuang
Copy link
Contributor Author

/gemini summary

@gemini-code-assist
Copy link
Contributor

Summary of Changes

This pull request introduces a significant enhancement to the stream processing engine by enabling the definition and processing of sub-events within event window triggers. This allows for more sophisticated and granular event detection, where a main event can be composed of several distinct sub-conditions. The changes ensure that the system can correctly identify, track, and notify about these complex event patterns, providing richer analytical capabilities for real-time data streams.

Highlights

  • Sub-Event Support for Event Windows: The EVENT_WINDOW trigger now supports defining multiple start conditions (sub-events) using a list in the START WITH clause, allowing for more complex event patterns.
  • Enhanced Event Notification Context: Event notifications generated by streamBuildEventNotifyContent now include conditionIndex and windowIndex to provide more granular details about which specific sub-event or window triggered the notification.
  • Dynamic Data Structure for Trigger Groups: The SSTriggerRealtimeGroup structure was updated with a union to manage state for different window types, specifically adding fields for parentWindow, numSubWindows, and conditionIdx to support nested event windows.
  • Object List Reordering Utility: A new utility function taosObjListMoveBefore was introduced to reorder elements within an object list, which is crucial for managing the order of calculation parameters in sub-event processing.
  • SQL Parser Extension: The SQL grammar (sql.y) and translator (parTranslater.c) were extended to parse and handle the new syntax for event windows with multiple start conditions.
Changelog
  • include/util/tobjpool.h
    • Declared taosObjListMoveBefore function for moving an object before a reference object in a list.
  • source/libs/new-stream/inc/streamInt.h
    • Modified streamBuildEventNotifyContent function signature to accept condIdx and winIdx parameters.
  • source/libs/new-stream/inc/streamTriggerTask.h
    • Updated SSTriggerRealtimeGroup struct with a union to encapsulate prevWindow, state window fields, and new sub-event window fields (parentWindow, numSubWindows, conditionIdx).
  • source/libs/new-stream/src/streamTriggerTask.c
    • Adjusted logic in stTriggerTaskDeploy to collect columns from start/end conditions, specifically handling QUERY_NODE_NODE_LIST for sub-events.
    • Enhanced stRealtimeContextCalcExpr to evaluate expressions that are node lists, assigning a uint8_t index to each matching condition.
    • Modified stRealtimeGroupDoEventCheck to process sub-events, manage parent and sub-windows, and re-evaluate rows when a sub-window closes due to a condition change.
    • Added a new static function stRealtimeGroupReorderCalcParams to reorder calculation parameters for sub-windows.
    • Updated stRealtimeGroupGenCalcParams to handle sub-event logic, including managing parent window notifications and calling stRealtimeGroupReorderCalcParams.
    • Modified stRealtimeGroupRetrievePendingCalc to prevent processing calculation parameters for sub-windows out of order.
    • Updated calls to streamBuildEventNotifyContent in stHistoryGroupDoEventCheck to pass new condIdx and winIdx parameters.
  • source/libs/new-stream/src/streamUtil.c
    • Implemented logic in streamBuildEventNotifyContent to include conditionIndex and windowIndex in the JSON notification content.
  • source/libs/parser/inc/sql.y
    • Added new grammar rules for EVENT_WINDOW to support START WITH (search_condition_list) syntax.
  • source/libs/parser/src/parTranslater.c
    • createStreamReqBuildTriggerEventWindow now checks if pEndCond is NULL before attempting to convert it to a string.
  • source/util/src/tobjpool.c
    • Implemented taosObjListMoveBefore to move an object within an object list.
Activity
  • Gemini Code Assist provided an initial summary of the pull request's changes.
  • Gemini Code Assist suggested changing pResCol->info.type from TSDB_DATA_TYPE_BOOL to TSDB_DATA_TYPE_UTINYINT for semantic correctness in stRealtimeContextCalcExpr.
  • Gemini Code Assist raised a concern about the i-- usage in stRealtimeGroupDoEventCheck for loop control, recommending refactoring or detailed comments. The author, JinqingKuang, responded by adding a detailed comment.
  • Gemini Code Assist questioned the robustness of the isParentWindow logic in stRealtimeGroupGenCalcParams, which relies on skey comparison. The author, JinqingKuang, clarified that the assumption holds due to time-ordered trigger data.
  • The author, JinqingKuang, requested a summary from Gemini Code Assist.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

2 participants