...
Table of Contents |
---|
All the development for the Apache Ignite 3.0.x happens in the dedicated repository: https://github.com/apache/ignite-3
TeamCity is currently set up to run all available JUnit tests (this will be changed in the future): https://ci.ignite.apache.org/project/ignite3
TeamCity triggers the test run for a pull request when it's created or updated. Upon completion, the PR is updated with the corresponding status which is shown as a successful or failed check.
The basic process to make a change is the following:
On the week of Sep 14th, we had two virtual events where the community discussed the proposed changes.
In English:
Widget Connector | ||
---|---|---|
|
In Russian:
Widget Connector | ||
---|---|---|
|
Slides are available here.
...
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(..)
).
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.
GraalVM is gaining a lot of popularity, especially in the context of serverless environments and frameworks like Micronaut and Quarkus. Currently, even Ignite thin client blocks software from being built into a native GraalVM image – this needs to be fixed. Preferably, we should support this for thick clients as well, although this is a lower priority and might require much bigger effort.
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.
List of proposed removals (WIP):
*Resource
annotations except for the IgniteInstanceResource
CacheRebalanceMode
and rebalance delay - should always work in the ASYNC
mode (current default)ASYNC
makes sense) and parametersIgniteFuture
with Java's CompletableFuture
String
, not a generic Serializable
objectLabel ignite-3
is used for any issues in JIRA that are related to Ignite 3.x.
Jira server ASF JIRA columns key,summary,type,updated,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery filter=12349470 serverId 5aa69414-a9e9-3523-82ec-879b028fb15b