Delete the incorrect configuration and modify the Chinese directory

Cause:
When the date in MySQL is 0, the value is considered to be null. MySQL handles this problem. If you query the statement of isull,
you will convert isnull to=0. This problem is that the value with the date of 0 is inserted into the table.
The query and deletion results of the tianmu engine are not consistent.
The reason for the inconsistency is that the syntax parsing logic of the query and deletion of tianmu is not the same
Solution:
Unified query logic and modification logic for date format processing.
Keep the phenomenon of tianmu consistent with innodb.

fix(tianmu): feature: The error display is too general, and the cause of the error cannot be clearly located #706

fix(tianmu): feature: The error display is too general, and the cause of the error cannot be clearly located #706

    fix(tianmu): Fixed tianmu syntax compatibility issue when continuous equivalent predicates are eliminated (#733)
    The root cause is that the tianmu syntax tree conversion
    cannot support continuous null-value elimination,
    and the cleaned equal-value elimination items are retained to be compatible with the tianmu execution plan

Cause:
There is a problem with the corresponding table index when creating entity columns
Solution:
When creating an entity column, the table index you try to import corresponds to the position in the tables list one by one

    The cause of an error is
    that you need to identify the returned
    result of the exists subquery for sl->join->zero_result_cause
    Determines whether a return value exists.
    and format query.cpp
:
The exists subquery determines whether a value exists during the query optimization phase

result is not set to zero only when a matching value is found in the query optimization phase

When a field has an index, the optimization phase scans the table through the index

The primary key implementation of the current column storage engine has a problem with the primary key index to scan the table for data

As a result, the primary key index is used to obtain the exists subquery result in the query optimization phase. Therefore, the exists subquery is not executed in the query execution phase

scan the table for data Remove the following temporary practices after primary key indexing is complete

    replace always true
    for examples:
    select * from t1 where b>2 or 1=2;
    select * from t1 where b>2 or 1<2;
    select * from t1 where b>2 or 1>2;
    select * from t1 where b>2 or 1=1;
    select * from t1 where b>2 or 1;
    select * from t1 where b>2 or 0;
    select * from t1 where ((((1=1) or (3=3)) and (3=3)) or ((1=100) and (5=a)));
    select * from t1 where ((((1=1) or (3=3)) and (3=4)) or ((1=100) and (5=a)));
    select * from t1 where ((((1=2) or (3=3)) and (3=3)) or ((1=100) and (5=a)));
    select * from t1 where ((((1>2) or (3=3)) and (3=3)) or ((1=1) and (5=a)));
    select * from t1 where ((((1=2) or (3<3)) and (3=3)) or ((1=1) and (5=a)));
    select * from t1 where ((((1=2) or (3<3)) and (3>1)) or ((1=1) and (5=a)));
    select * from t1 where ((((1=2) or (3=3)) and (3=1)) or ((1>1) and (5=a)));

[summary]
1 the root reason is because of the variable ‘tianmu_insert_delayed’,set it off;
2 in debug version, it crashes, fix it;
3 add mtr case for this issue;

Replace the function FindCurrentRowByVMTable that gets the current row to FindCurrentRow.

Cause:
At present, the primary key of the tianmu engine does not fully support delete and update statements.
Temporary solution:
Modify the execution plan of the SQL layer so that the delete and update statements do not follow the primary key logic

feat(tianmu)The tianmu engine throws exception modification and specific exception information to the client

Cause:
no_dims is a destination number of dimensions.
It needs to be increased according to the number of executions.
But the logic here is that whether the table is involved in execution or not, it will lead to the increase of (no_dims),
This in turn causes the subsequent pack index to exceed the length of the index array.
Solution:
Optimize the logic of (no_dims) increasing to make it increase reasonably

    fix issuse 468 461 mtr result

    The reason for the error lies in that in Item_cond_or condition,
    sub-conditions similar to a=a will be cleared after
    elimination of equivalent conditions,
    but the tianmu engine does not do additional scene
    processing for the remaining conditions after elimination
    of equivalent conditions of Item_cond_or.
    Results in a scenario where
    only the remaining predicates are processed
    and the or predicates are not considered.

    The corresponding issuse:
    https://github.com/stoneatom/stonedb/issues/301
    https://github.com/stoneatom/stonedb/issues/733

    revert code style

* feat(website): Upgrade the official website

Rebuild and upgrade the official website

style(clangformat): change the parameter of clangformat AllowShortIfStatementsOnASingleLine to Never

Cause:
Execution plan error when AND/OR sql logical operator in condition occurs at the same time
Resolvent:
Optimize multiple equal execution plan logic

Cause of the problem:
The tianmu engine created join objects in syntax optimization, but did not explain them
Modify Scheme:
Release the join object after use