03-TriggerMode¶
¶
Trigger mode count
Verification testing during the development process.
1. Create database and super table
2. Create sub tables
3. Create streams with count trigger mode
4. Insert data into sub tables
5. Check stream results
¶
Trigger mode count many
1. Create database and super table
2. Create sub tables
3. Create streams with count trigger mode
4. Insert data into sub tables
5. Check stream results
¶
Trigger mode count
1. Create snode and database
2. Create super table and sub tables
3. Create streams with count_window trigger mode
4. Insert data into source tables
5. Check stream results
¶
Trigger mode stable event
1. Create snode and database
2. Create super table and sub tables
3. Create streams with event_window trigger mode
4. Insert data into source tables
5. Check stream results
¶
Trigger mode event
Verification testing during the development process.
¶
Options: fill history
1. Create snode and database
2. Create super table and sub tables
3. Create streams with fill_history option
4. Insert data into source tables
5. Check stream results
¶
Trigger mode sliding: const lower-bound with _twstart
Reproduce bug where stream runtime fails when the query filter mixes:
- constant timestamp lower-bound
- window placeholder upper-bound (_twstart)
¶
Options: period
1. Create 10 streams, each stream has 10 source tables
2. Write data to source tables
3. Check stream results
4. Drop streams and tables
¶
Test PERIOD trigger with natural time units (week/month/year)
Purpose: Comprehensive tests for stream PERIOD trigger with natural time units
Steps:
1. Test week unit (PERIOD(1w), PERIOD(2w))
2. Test month unit (PERIOD(1n), PERIOD(3n))
3. Test year unit (PERIOD(1y), PERIOD(2y))
4. Test offset parameter (PERIOD(1w, 1d), PERIOD(1n, 14d))
5. Test validation errors (invalid units, out-of-range, offset overflow)
Expected: All natural time unit syntax accepted, proper validation, metadata stored correctly
¶
Options: sliding
1. Create stream with sliding trigger mode, different partition by columns and sliding time.
2. Execute various queries on the stream with different calculation tables and validate the results.
3. Validate the results against expected outputs or result files.
4. Clean up the created streams and databases after test execution.
¶
Sliding trigger should continue checking after one calc batch
1. Create a sliding stream with 1ms(step unit `a`) and calc based on %%trows.
2. Insert trigger rows spanning more than STREAM_CALC_REQ_MAX_WIN_NUM windows.
3. Verify all windows are eventually materialized instead of stopping after the first batch.
¶
Trigger mode state window
1. Create snode and database
2. Create super table and sub tables
3. Create streams with state_window trigger mode
4. Insert data into source tables
5. Check stream results
¶
Options: state window stable
1. create 14 streams, each stream has 1 source tables
2. write data to source tables
3. check stream results
¶
Options: state window close
Test window close trigger mode with state window windows
1. create streams with state window windows
2. write data to source tables with state window gaps
3. check stream results
¶
Stream event window
Description:
- Create a stream for a virtual table with an event window trigger mode
- Map table d1.t1.a to a data column of the virtual table
- Write data to d1.t1 and verify the stream calculation results
- Map table d2.t2.b to a data column of the virtual table
- Write data to d2.t2 and verify the stream calculation results
¶
Verify the functionality of TRUE_FOR expr.
This case validates the `TRUE_FOR` expr across various scenarios. It
covers application in both queries and stream computing, specifically
focusing on `EVENT_WINDOW` and `STATE_WINDOW`. The case includes all
four modes of `TRUE_FOR`:
- `TRUE_FOR(duration_time)`
- `TRUE_FOR(COUNT n)`
- `TRUE_FOR(duration_time AND COUNT n)`
- `TRUE_FOR(duration_time OR COUNT n)`
It ensures correct behavior under normal conditions, edge cases, and
error scenarios.