THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
Page History
...
| API | +1 (explain if needed) | -1 (with explanation) |
|---|---|---|
| Already deprecated APIs | ||
| Local caches | Alexey Kuznetsov Can we "emulate" local cache by partitioned with "node filter to one node"? Alexey Goncharuk Local cache is meaningless in a distributed system, especially when a transaction is involved: suppose a prepare step completed and a node with local cache goes down. According to 2PC, we cannot proceed until the node goes up again | |
| Spatial indexes | Denis Magda - the API is broken and not suited for production. Can be designed from scratch with Ignite 3.1 and 3.2. | Alexey Zinoviev It could be removed only in the 3.1 then the new implementation will be provided in other case we will poor with indices |
| Full-text search | Denis Magda - the API is broken and not suited for production. Can be designed from scratch with Ignite 3.1 and 3.2. | Alexey Zinoviev It could be removed only in the 3.1 then the new implementation will be provided in other case we will poor with full-text indices |
| Checkpointing SPI | Denis Magda - Ignite caches/tables can be used to store the checkpoints. This API is redundant. | |
| Ignite.lock | Alexey Goncharuk The distributed lock concept is broken (see corresponding Aphyr video). The usual lock usage pattern is lock - update cache - unlock. The same semantics can be achieved using pessimistic transactions with keys locking, but instead, for an end-user, it is clear how lock can fail in a distributed system (transaction rollback). Pavel Kovalenko Very fragile API. Not tested well. Some failures can lead to unavailability of controlling such locks. Can be returned back and reworked after implementation of some consensus algorithm like Raft. | Denis Magda - unless an alternate solution is provided as part of existing Transactional APIs. There has to be a clear migration guide for Ignite.lock customers. Alexey Zinoviev It could be removed only in the 3.1 then the new implementation will be provided |
| Cache.lock | Alexey Goncharuk Same arguments as with Ignite.lock, but even more redundant API | Alexey Zinoviev It could be removed only in the 3.1 then the new implementation will be provided |
| Ignite Data Structures | Pavel Kovalenko Can be marked as not safe and reworked after implementation of some consensus algorithm like Raft. Ivan Pavlukhin The implementation quality is really not sufficient. As for me data structures in current flavor should not be used in production. We can deprecate current implementation as a first step. Later on we can add all necessarry implementations as they are ready and a required development effort seems not trivial. | Denis Magda - that's basic functionality of every IMDG and in-memory cache. We can't remove it. Instead, let's plan through activities that improve or reconsider current implementations. Alexey Zinoviev Agree with Denis Magdaalso we should extend the list of basic structures (ready to help) |
| GAR files | Denis Magda - to be replaced with JARs | |
"Force server mode" for client nodes | Denis Magda - don't see any value any longer. Alexey Goncharuk Already deprecated | |
| Daemon nodes | Denis Magda - Visorcmd has to be preserved and updated to another protocol Alexey Kuznetsov - Visorcmd should be merged with controls.sh | |
| CacheRebalanceMode.NONE and Rebalance Delay | Denis Magda - it can break data consistency in a cluster. Also, remove force rebalance mode as it can be used only if rebalance delay is set. Alexey Goncharuk The mode does not make sense, cannot be explained to an end-used | |
| Indexing SPI | Denis Magda - it's highly unlikely that anybody used this. The community supports all the querying engines on its own. | |
| QueryEntities and Annotations based configuration of SQL | Denis Magda - Alexey Goncharuk is going to propose an alternate API that unites these concepts. Sergey Kozlov - require full redesign, it should be fully compatible JDBC SQL and visa-versa | |
| @CentralizedAffinityFunction | Alexey Goncharuk This API is no longer needed after exchange merge was introduced | |
| IgniteCache localPeek/localEntries | Ivan Pavlukhin These methods look more like a debug stuff and have confusing semantics. At least should be moved outside of IgniteCache facade. |
...
Overview
Content Tools
Apps