[
https://issues.apache.org/jira/browse/IGNITE-28699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kratika Agrawal updated IGNITE-28699:
-------------------------------------
Description:
Problem
Ignite 2.x exposed `CacheStore<K,V>` (load / loadAll / write / writeAll /
delete) plugged in via
`CacheConfiguration.setCacheStoreFactory(...)` + `setReadThrough(true)` /
`setWriteThrough(true)`.
This let applications integrate Cassandra, Oracle, JDBC, or custom stores as a
transparent
backing store: a cache miss called `load(key)`, a `put` called `write(entry)`,
etc.
Ignite 3.1.0 removed both the `CacheStore` interface and the
`CacheConfiguration` SPI used to
register it. There is no documented replacement in the Table / KeyValueView /
RecordView APIs.
Ask
1. *{*}Restore an equivalent SPI{*}* on `Table` / `KeyValueView`: e.g.
`tableConfiguration.cacheStoreFactory(...)` with `load(key)` /
`write(entry)` / `delete(key)`
hooks fired by the storage engine on miss / put / remove.
2. If a restoration is out of scope, document the intended 3.x pattern for
"external system
of record + Ignite cache" deployments. Today's options
(custom interceptors? compute jobs? application-side wrappers?) are not
specified.
3. Is this a regression — 2.x users migrating to 3.x lose a first-class
integration
point with no documented path forward.
was:
### Problem
Ignite 2.x exposed `CacheStore<K,V>` (load / loadAll / write / writeAll /
delete) plugged in via
`CacheConfiguration.setCacheStoreFactory(...)` + `setReadThrough(true)` /
`setWriteThrough(true)`.
This let applications integrate Cassandra, Oracle, JDBC, or custom stores as a
transparent
backing store: a cache miss called `load(key)`, a `put` called `write(entry)`,
etc.
Ignite 3.1.0 removed both the `CacheStore` interface and the
`CacheConfiguration` SPI used to
register it. There is no documented replacement in the Table / KeyValueView /
RecordView APIs.
### Ask
1. **Restore an equivalent SPI** on `Table` / `KeyValueView`: e.g.
`tableConfiguration.cacheStoreFactory(...)` with `load(key)` /
`write(entry)` / `delete(key)`
hooks fired by the storage engine on miss / put / remove.
2. If a restoration is out of scope, document the intended 3.x pattern for
"external system
of record + Ignite cache" deployments. Today's options
(custom interceptors? compute jobs? application-side wrappers?) are not
specified.
3. Is this a regression — 2.x users migrating to 3.x lose a first-class
integration
point with no documented path forward.
> External Store / CacheStore SPI: no read-through / write-through in Ignite
> 3.x (regression from 2.x)
> ----------------------------------------------------------------------------------------------------
>
> Key: IGNITE-28699
> URL: https://issues.apache.org/jira/browse/IGNITE-28699
> Project: Ignite
> Issue Type: Improvement
> Components: storage engines ai3
> Environment: **Apache Ignite:** 3.1.0 (migrated from 2.17.0)
> - **JDK:** Java 21 (LTS), `--enable-native-access=ALL-UNNAMED` required for
> module access
> - **Topology:** Multi-node clusters; tested with 2-node and 3-node
> SharedNothing deployments,
> co-located on a single host as well as across hosts. `raft.fsync=true`
> auto-enabled for
> SharedNothing to survive ungraceful restarts.
> - **Storage profiles:** Mix of `aipersist` (persistent) and `aimem`
> (in-memory) regions per
> table. External backing stores in use: Cassandra, Oracle, JDBC, custom DAO.
> Reporter: Kratika Agrawal
> Priority: Major
>
> Problem
> Ignite 2.x exposed `CacheStore<K,V>` (load / loadAll / write / writeAll /
> delete) plugged in via
> `CacheConfiguration.setCacheStoreFactory(...)` + `setReadThrough(true)` /
> `setWriteThrough(true)`.
> This let applications integrate Cassandra, Oracle, JDBC, or custom stores as
> a transparent
> backing store: a cache miss called `load(key)`, a `put` called
> `write(entry)`, etc.
> Ignite 3.1.0 removed both the `CacheStore` interface and the
> `CacheConfiguration` SPI used to
> register it. There is no documented replacement in the Table / KeyValueView /
> RecordView APIs.
> Ask
> 1. *{*}Restore an equivalent SPI{*}* on `Table` / `KeyValueView`: e.g.
> `tableConfiguration.cacheStoreFactory(...)` with `load(key)` /
> `write(entry)` / `delete(key)`
> hooks fired by the storage engine on miss / put / remove.
> 2. If a restoration is out of scope, document the intended 3.x pattern for
> "external system
> of record + Ignite cache" deployments. Today's options
> (custom interceptors? compute jobs? application-side wrappers?) are not
> specified.
> 3. Is this a regression — 2.x users migrating to 3.x lose a first-class
> integration
> point with no documented path forward.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
