close #862

Development

• [x] SQL syntax https://github.com/4paradigm/zetasql/pull/41
• [x] extend BinaryExpr to support RLIKE type
• [x] add regexp_like builtin function
• [x] Codegen: deal with RLIKE BinaryExpr

Test

• [x] ~~logic plan test in ast_node_converter_test to verify correctly plan generated for rlike expr (discuss needed)~~
• [x] unit test for new functions in udf.cc -> udf_test.cc
• [x] udf_ir_builder_test for the registered function regexp_like udf functions
• [x] expr_ir_builder_test for the supported rlike expression
• [x] and end2end, a full sql example to test correctly for both rlike expression and regexp_like function (discuss needed)

• Please check if the PR fulfills these requirements

• [ ] The commit message follows our guidelines
• [ ] Tests for the changes have been added (for bug fixes / features)
• [ ] Docs have been added / updated (for bug fixes / features)

• What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

• What is the current behavior? (You can also link to an open issue here)

• What is the new behavior (if this is a feature change)?

• Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)

• Other information:

Bug Description

  - id: 6
    desc: window merge optimization
    inputs:
      - columns: [ "row_id int","ts timestamp","group1 string","val1 int" ]
        indexs: [ "index1:group1:ts" ]
        name: t1
        data: |
          1, 1612130400000, g1, 1
          2, 1612130401000, g1, 2
          3, 1612130402000, g1, 3
          4, 1612130403000, g1, 4
          5, 1612130404000, g1, 5
    sql: |
      select
      `row_id` as row_id_1,
      `row_id` as t1_row_id_original_0,
      case when !isnull(at(`val1`, 0)) over t1_group1_ts_0s_5s_10 then count_where(`val1`, `val1` = at(`val1`, 0)) over t1_group1_ts_0s_5s_10 else null end as t1_val1_window_count_1,
      case when !isnull(at(`val1`, 0)) over t1_group1_ts_1s_5s_10 then count_where(`val1`, `val1` = at(`val1`, 0)) over t1_group1_ts_1s_5s_10 else null end as t1_val1_window_count_2
      from
        `t1` WINDOW
        t1_group1_ts_0s_5s_10 as (partition by `group1` order by `ts` rows_range between 5s preceding and 0s preceding MAXSIZE 10),
        t1_group1_ts_1s_5s_10 as (partition by `group1` order by `ts` rows_range between 5s preceding and 1s preceding MAXSIZE 10);
    expect:
      columns: ["row_id_1 int", "t1_row_id_original_0 int", "t1_val1_window_count_1 int64", "t1_val1_window_count_2 int64"]
      order: row_id_1
      data: |
        1, 1, 1, 0
        2, 2, 1, 0
        3, 3, 1, 0
        4, 4, 1, 0
        5, 5, 1, 0

Expected Behavior

the case should pass. Current result is not:

+----------+----------------------+------------------------+------------------------+
| row_id_1 | t1_row_id_original_0 | t1_val1_window_count_1 | t1_val1_window_count_2 |
+----------+----------------------+------------------------+------------------------+
| 1        | 1                    | 1                      | NULL                   |
| 2        | 2                    | 1                      | NULL                   |
| 3        | 3                    | 1                      | NULL                   |
| 4        | 4                    | 1                      | NULL                   |
| 5        | 5                    | 1                      | NULL                   |
+----------+----------------------+------------------------+------------------------+

Work List

• [x] add extra handling in logic plan for lag functions
  • working in #1605
• [x] fix lag correctness in request mode & cluster environment
• [x] fix window merge result correctness ( may related to #1587 )

This PR try to solve the problem that some api don't follow google cpp style.

The thing this PR has done:

• [x] Change the api of EngineOptions and JitOptions' methods to follow google cpp style name

The related issues gitee related issue 286

This PR try to solve the problem that some api don't follow google cpp style.

background cpp code should follow our style guide: https://github.com/4paradigm/rfcs/blob/main/style-guide/code-convention.md

The thing this PR has done:

• [x] Change the api of EngineOptions and JitOptions' methods to follow google cpp style name, just leave the corresponding part in openmldb-batch unchanged

The related issues gitee related issue 286

• What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

Adds the dayofyear() function which returns the day of the year for a given date (a number from 1 to 366).

• What is the current behavior? (You can also link to an open issue here)

dayofyear function doesn't exist, see issue for more details: #785

• What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

Feature: implement built-in function last_day

• What is the new behavior (if this is a feature change)?

Closes #821

• What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

feature

• What is the current behavior? (You can also link to an open issue here)

https://github.com/4paradigm/OpenMLDB/issues/1639

• What is the new behavior (if this is a feature change)? add a udf function similar to Hive get_json_object

Features

resolve #224 detail sql rules found in #224 and #686

What not implemented yet:

• convert and into string if possible, currently only support string or null
• data exception: invalid escape sequence is not checked

Further work

• Implicit conversion for like's <target expression> & <pattern expression>
• support RLIKE/SIMILAR TO predicate (regexp_match)

Uncompleted.

• add the document for the second task in #1707 : udf doc gen
  • there needed extra code to make steps work
• also to metion #807, which related to linked udf doc problems

• What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

• What is the current behavior? (You can also link to an open issue here)

• What is the new behavior (if this is a feature change)?

• What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

• What is the current behavior? (You can also link to an open issue here)

• What is the new behavior (if this is a feature change)?

CallablePreparedStatement -> RequestPreparedStatement -> PreparedStatement It can do

stmt = create()
for i:
  stmt.setXX()
  stmt.executeQuery() # in dataBuild, it'll clearParameters()

• [ ] Add a best practice and ut for it.

It's not good to create the stmt every time, cuz ctor is a little complex.

https://github.com/4paradigm/OpenMLDB/blob/f349d7242b1f08ac3b467bdbc2deb507ab73883e/java/openmldb-jdbc/src/main/java/com/_4paradigm/openmldb/jdbc/CallablePreparedStatement.java#L31

Bug Description The following example configs should also be added to the docs/en/deploy/conf.md

#
# HDD表数据文件路径（可选，默认为空）
# 配置数据目录，多个磁盘使用英文符号, 隔开
--hdd_root_path=./db_hdd
# 配置数据回收站目录，drop表的数据就会放在这里
--recycle_bin_hdd_root_path=./recycle_hdd
#
# SSD表数据文件路径（可选，默认为空）
# 配置数据目录，多个磁盘使用英文符号, 隔开
--ssd_root_path=./db_ssd
# 配置数据回收站目录，drop表的数据就会放在这里
--recycle_bin_ssd_root_path=./recycle_ssd

Expected Behavior

Relation Case

Steps to Reproduce