We’re pleased to announce immudb version 1.3. This version brings some new notable changes, 40% higher performance and a lot of other improvements and some bug fixes.
You can find the new release here for all major platforms:
https://github.com/codenotary/immudb/releases/tag/v1.3.0
Regarding SDKs, please make sure to check the compatibility list:
https://docs.immudb.io/master/getstarted/jumpstart.html
In response to its growing popularity and increasing adoption by enterprises, Codenotary, the primary contributor to the open source immudb, provides three levels of support.
In this version we’ve extended queries on the KV level by adding value revisions. This brings up an easy to use and elegant way to access historical values for keys such as getting the first version (revision 1) or a previous value (revision -1). You can quickly check how it works with newest immuclient
by following our updated User quickstart guide or by writing an application using revision using our SDKs.
ALTER TABLE
This version also brings the initial support for ALTER TABLE
statements in the SQL layer. We’ve added support for ADD COLUMN
and RENAME COLUMN
operations.
When dealing with historical values on the SQL layer, it is now possible to use time expressions next to transaction ids for specifying historical values. Queries such as SELECT * FROM sales SINCE '2022-01-06 11:38' UNTIL '2022-01-06 12:00'
are now perfectly valid. You can find more info in the SQL reference.
Information about the SQL catalog can now be read directly using SQL. For that purpose we’ve added few built-in functions into our SQL dialect such as DATABASES()
. Read more about this feature in the SQL reference
In this release we also worked on the immudb documentation available at https://docs.mmudb.io/. Next to hundreds of smaller changes, the new menu structure will help finding useful resources. Most notably, the developer documentation is now split between the Key Value and SQL operations.
There are many more features added in this release. Most notably immudb now supports the USE [DATABASE] <dbname>
and UNION SELECT
SQL statements increasing the SQL compatibility. In addition to that, the Scan operation on the KV layer has now extended set of parameters allowing much greater filtering of scanned results.
Starting with 1.3 release, immudb will now return an error if the amount of rows returned from the Scan
, TxScan
and ZScan
will be greater than the allowed maximum (1000) and the limit argument was not set. We’ve found out that the previous behavior lead to a very dangerous and hidden bugs if the caller made an assumption that those calls returned all available results if the limit was not given.
To retrieve results larger than 1000 elements, pagination with a proper limit value should be used. This is the same requirement as before however it currently requires explicit limit value.
In order to handle arbitrary result sizes, future releases of immudb will focus on streaming APIs where entries will be retrieved from the server in an incremental way.
You can find the full change log and the release download here: