Page History

...

Release Manager

Apache Ignite 3.0Valentin Kulichenko

Major Changes and Features

...

Currently, query API is attached to the cache API. I.e., to execute a query, one needs to create a cache first. This is incompatible with SQL-only use cases where all the tables are created via DDL. In this use case, executing a SQL query requires that the user creates a dummy cache without no data and uses this cache as an API gateway. This is very counterintuitive. Instead, we should have a designated API for SQL, which would be located on the top level (e.g. ignite.sql().executeQuery(..) ).

Modularization

Ignite consists of many modules, most of which are optional and are not used by the majority of our users. Still, we deliver binaries as a single package, which the user has to modify manually by moving folders around. In addition, the package contains configuration files, as well as multiple startup scripts. One of the biggest issues is related to upgrades: if anything within the package is modified (one of the scripts, a configuration file, a set of enabled modules, etc.), these changes then must be somehow merged with the new version of the package. There is no clear standard way of doing this, which makes the whole process very counterintuitive and error-prone.

We need to come with a better way of modularizing the platform and apply it to all available ways of delivery (downloadable ZIP, RPM, DEB, etc.). Can we utilize Java modularization somehow?

Some of the modules (mainly, integration components and thin clients) can be isolated into separate projects with independent lifecycles.

Cleanup

Ignite 3.0 is a major release, which gives us a unique opportunity to make incompatible changes. This can be used to do a cleanup and remove deprecated APIs and features. Additionally, all APIs should be revisited from this point of view – anything that is not relevant anymore should be removed from the project; some APIs can be reworked and modernized.

TBD: full list of removals.