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:
      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]
      The behavior of parameter keyPurgeDaily has changed:
      • 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 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).
    If these limits are exceeded, the system will raise an error.
  • 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:
    Memory size of append transaction 2000000216 exceeds max limit (429496729) for OLAP. Please split data into batches.
    To retain the behavior of previous releases, this limit can be removed or relaxed using one of the following methods:
    • 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.

    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
    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.
  • 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 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.
    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
    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.

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:
    // Previous version
    spawnMonitor(handler, args...)
    // New version
    spawnMonitor(name, handler, args...)
    name uniquely identifies the newly spawned monitor. If the name is duplicate with an existing monitor, spawnMonitor will fail and raise an error.