2.00.16

2.00.16.4

When a dictionary or tuple contains nested dictionaries or tuples, the behavior of modifying the nested elements using in-place functions such as append! has changed:

  • In previous versions, the modification had no effect and no error was raised;

  • Starting from the new version, in-place modifications are supported and take effect immediately.

tp = [dict([1,2],[3, 4]), (1, 2, 3)]
tp[1].append!(4)
print tp

/* Previous version: the modification has no effect and no error is raised; the result remains unchanged.
(2->4
1->3
,(1,2,3))
*/

/* New version: the modification takes effect, and the result reflects the changes.
(2->4
1->3
,(1,2,3,4))
*/

2.00.16.1

Changes Made to Match Industry Practices

  • Modified the parameters of bondAccrInt, bondCashflow, bondConvexity, bondDirtyPrice, bondYield for improved consistency and functionality. Some parameter names have been changed, and the original signatures are no longer compatible. Please adapt your code accordingly.

2.00.16.0

System Impacts Caused by Bug Fixes

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