3.00.3
System Impacts Caused by Bug Fixes
-
Enhanced parameter validation in
elasticNetCV
,lassoCV
,ridgeCV
functions:- In previous releases, parameters yColName and xColNames could take temporal columns.
- Since this release, parameters yColName and xColNames only support numeric columns. Otherwise, an error will be raised.
-
Modified the data form returned by the
iif
function and the ternary operator?:
:- In previous releases, the return value was primarily determined based on the data form of trueResult and falseResult.
- Since this release, the return value is consistent with the data form of cond.
iif([true,false],1:2,(3..4$1:2)) true false?(1:2):(3..4$1:2) // Output (previous releases): INT PAIR 1:4 // Output (current release): FAST INT VECTOR [1,4]
-
Modified NULL value handling in the
seq
function when either start or end was NULL:- In previous releases, incorrect results were returned.
- Since this release, an error is reported.
-
For tables containing LONG or NANOTIMESTAMP columns using the delta of delta compression method (i.e.,
compressMethods="delta"
), if delta-of-delta values overflow:- In previous releases, data flushing failed and server continuously retried, causing the system to hang.
- Since this release, overflowed data is converted to null values.
dbName = "dfs://test" if(existsDatabase(dbName)) { dropDatabase(dbName) } db = database(dbName,HASH, [INT, 1]) t = table(10:0,[`id, `data],[INT, LONG]) pt = db.createPartitionedTable(t, `pt, `id, {data:"delta"}) t = table(1..5 as id, [1,1,8704332179800340403, 105, 27162335252578330] as data) pt.append!(t) purgeCacheEngine() sleep(1000) select * from pt
Query results in this version:
id data 1 1 2 1 3 8,704,332,179,800,340,403 4 5 -
When both the THEN and ELSE clauses of a SQL CASE statement involve the
string
function and return a scalar, the result was of STRING type in previous versions. Since this release, the result is of SYMBOL type.t = table(0 NULL 1 as id) re = select case when id=0 then string("a") else string("b") end from t select name,typeString from schema(re).colDefs // Previous releases: col1 is of STRING type // Ccurrent release: col1 is of SYMBOL type
-
Modified data sorting behavior in the
varma
function when input ds is a DATASOURCE vector:- In previous releases, the model automatically sorted data by the first column.
- Since this release, data is only sorted when the first column is of temporal types.
-
Modify the visibility scope of databases when non-admin users execute
getClusterDFSDatabases
:- In previous releases, it returned DFS databases where the user had DB_MANAGE permission or databases created by the user.
- Since this release, it additionally returns DFS databases where the user has DB_READ/DB_INSERT/DB_UPDATE/DB_DELETE/DBOBJ_CREATE/DBOBJ_DELETE permissions.
- In SQL EXEC statements, when both DISTINCT and an aggregate function are used in
a query involving table joins, the previous release returned a scalar result.
Since this release, the result is returned as a
vector.
sym = `C`MS`MS`MS`IBM`IBM`C`C`C$SYMBOL price= 49.6 29.46 29.52 30.02 174.97 175.23 50.76 50.32 51.29 qty = 2200 1900 2100 3200 6800 5400 1300 2500 8800 t1 = table(sym, qty); t2 = table(sym, price); x = exec distinct count(price) from t1 full outer join t2 on t1.sym=t2.sym; typestr x; // Output (previous releases): INT // Output (current release): FAST INT VECTOR
- Modified the behavior of
createDailyTimeSeriesEngine
:- When sessions are defined, the roundTime parameter is no longer applied, and mergeLastWindow no longer adjusts or aligns the session boundaries.
- When defining a cross-day session as
follows:
The behavior of parameter keyPurgeDaily has changed:sessionBegin = [00:00:00, 09:00:00, 13:00:00, 21:00:00] sessionEnd = [01:00:00, 11:30:00, 15:00:00, 00:00:00]
- In previous releases, keyPurgeDaily was not effective before 21:00:00. Data between 15:00:00 and 21:00:00 was merged into the window starting at 21:00:00.
- Since this release, keyPurgeDaily takes effect before 21:00:00. Data between 15:00:00 and 21:00:00 will be discarded.
- When a user's permissions change:
- In previous releases, the user could activate their updated permissions
within the current session by switching to a different user and then
logging (
login
) back in. - In the new release, the user must explicitly
logout
and log back in to apply the updated permission settings.
- In previous releases, the user could activate their updated permissions
within the current session by switching to a different user and then
logging (
- In the return value of the
getUserAccess
function, the field name "COMPUTE_GROUP_allowed" has been renamed to "COMPUTE_GROUP_EXEC_allowed" starting from the new release. - Since this release, limits have been introduced for SQL WHERE clauses:
- A maximum of 1,024 conditions (comma-separated) is allowed in a WHERE clause.
- Each condition expression can contain up to 1,024 operators (including AND).
- Snapshot engines (created with
registerSnapshotEngine
) are no longer supported since this release. Users are advised to switch to the IOTDB engine (created via the CREATE statement) which provides equivalent functionality for retrieving the latest record in each group. - In previous releases, there was no limit on the volume of data written in a
single transaction. Starting from the new release, a limit has been introduced
to improve system stability. By default, the maximum size for a single
transaction is restricted to 20% of the cache engine capacity. If the data
exceeds this limit, an error will be raised. For
example:
To retain the behavior of previous releases, this limit can be removed or relaxed using one of the following methods:Memory size of append transaction 2000000216 exceeds max limit (429496729) for OLAP. Please split data into batches.
- Set the configuration parameter maxTransactionRatio=1 to allow transactions up to 100% of the cache engine capacity;
- Or call
setMaxTransactionSize
at runtime to adjust the limit dynamically.
- In previous releases, for in-memory tables, if a column was created using tuples
(i.e., ANY) containing elements of the same type, the system would automatically
convert that column to a ColumnarTuple type. After this conversion, the column
would no longer accept values of different types—any attempt to insert such data
would result in an error.
In the new release, this automatic conversion is no longer performed. The column remains of type ANY, allowing insertion of mixed-type data.
To maintain compatibility with the previous behavior, a configuration parameter autoConversionToColumnarTuple has been introduced. Its default value is false, meaning the system follows the new behavior (no automatic conversion). To restore the legacy behavior, set this parameter to true.id = 1 2 3 val = [[1,2,3,4], [4,5,6],[7,8,9]] t = table(id, val) isColumnarTuple(t[`val]) // Output (previous releases): true // Output (current release): false insert into t values(1, "a") // Error raised in previous releases: Failed to append data to column 'val'. insert into t values(1, "a") // Inserted successfully in current release
- Enhanced parameter validation for the anomaly detection engine. When illegal
metrics parameters are passed to the
createAnomalyDetectionEngine
function:- In previous releases, the function execution wouldn't immediately report
errors. Instead, error messages would be output through the
getStreamEngineStat
function after data writing. - Since this release, the system will immediately throw an exception during engine creation.
- In previous releases, the function execution wouldn't immediately report
errors. Instead, error messages would be output through the
- In SQL distributed queries, if the SELECT statement references
tableName.colName
and the FROM clause contains a subquery with a JOIN, the new version requires the subquery to be explicitly assigned an alias using AS. Otherwise, it will raise the error:SQL context is not initialized yet
.
Using SELECT * after joining multiple tables can result in high memory usage. It is recommended to explicitly specify the required columns in the SELECT clause to avoid unnecessary resource consumption and potential performance issues.dbName = "dfs://test" if(existsDatabase(dbName)){ dropDatabase(dbName) } db = database(dbName, VALUE, 1..100) n = 100 t = table(take(0..30, n) as id, rand(10 ,n) col1, rand(10 ,n) col2) pt1 = db.createPartitionedTable(t, `pt1, `id).append!(t) pt2 = db.createPartitionedTable(t, `pt2, `id).append!(t) // In previous releases, table alias is not required select pt1.id in 1..5 from (select * from pt1 full join pt2 on pt1.col1=pt2.col1) // Since this release, table alias must be specified select pt1.id in 1..5 from (select * from pt1 full join pt2 on pt1.col1=pt2.col1) as pt1
CEP monitor interface behaviors have been updated as follows:
- Since this release, all monitor classes must explicitly inherit from
CEPMonitor
.// Previous version class mainMonitor{ ... } // New version class mainMonitor:CEPMonitor{ ... }
- When using
getDataViewEngine
within a CEP monitor to access DataView engine, the previous version required the CEPEngine argument to be empty. This release allows directly passing the DataView engine name:// Previous version getDataViewEngine(, 'traderDV') // New version getDataViewEngine('traderDV')
- In previous versions, calling
dropStreamEngine
inside a CEP monitor could remove external streaming engines. Since this release, it can only remove stream engines created within the current CEP engine. - The
spawnMonitor
interface now includes a new name parameter:
name uniquely identifies the newly spawned monitor. If the name is duplicate with an existing monitor,// Previous version spawnMonitor(handler, args...) // New version spawnMonitor(name, handler, args...)
spawnMonitor
will fail and raise an error.