Responde me a essas 4 perguntas, pesquisando na do...

Pesquisei na documentação e Javadocs do Apache Ignite 3.1.0. Há algumas diferenças importantes em relação às hipóteses que tinhas — sobretudo porque Ignite 3 deixou de ter a antiga Cache API como API principal.

1. Como se cria uma ligação thin client em Ignite 3.1?

Em Ignite 3 já não há a distinção “thin vs thick client”: todos os clients são thin. O Java client usa o artefacto ignite-client:3.1.0 e a ligação é criada com IgniteClient.builder(). Não se usa Ignition.startClient(...), nem ClientConnectorAddress. (Apache Ignite)

xml
<dependency>
    <groupId>org.apache.ignite</groupId>
    <artifactId>ignite-client</artifactId>
    <version>3.1.0</version>
</dependency>

java
IgniteClient client = IgniteClient.builder()
    .addresses("ignite-node-1:10800", "ignite-node-2:10800")
    .build();

Portanto, num projecto Spring, o equivalente ao vosso antigo IgniteConfig.java pode realmente ficar muito pequeno:

java
@Configuration
public class IgniteConfig {

    @Bean(destroyMethod = "close")
    IgniteClient igniteClient() {
        return IgniteClient.builder()
            .addresses("ignite-node-1:10800", "ignite-node-2:10800")
            .build();
    }
}

O ponto arquitectural mais importante é que o client não se torna membro do cluster, não guarda dados e não é destino de compute jobs. Assim, os antigos IgniteSpringBean, IgniteConfiguration, Discovery SPI, Communication SPI e afins não são “convertidos” para configuração do client. A configuração de rede, storage, discovery, etc. passa a pertencer aos nós/cluster Ignite, normalmente em HOCON/JSON/CLI. (Apache Ignite)

Conclusão: para o código da aplicação, sim: 291 linhas podem plausivelmente transformar-se em ~5–15 linhas. Mas os SPIs não desapareceram todos conceptualmente; a parte que pertence à infraestrutura muda para configuração do cluster.

---

2. O que um thin client PODE fazer em 3.1?

A Javadoc é particularmente útil aqui. IgniteClient implementa Ignite, e a API pública de Ignite em 3.1 expõe essencialmente catalog(), cluster(), compute(), sql(), tables() e transactions(). Não existem aí cache(), events(), services() ou semaphore(). (Apache Ignite)

Código antigo / pretendido	Ignite 3.1	Substituição	Categoria
client.cache("FX_RATE")	Não	client.tables().table("FX_RATE") + KeyValueView/RecordView	TROCA DIRECTA se for CRUD simples; senão REIMAGINE
client.cache(...).lock(key)	Não	Não há explicit distributed key lock equivalente; usar transações quando adequado	REIMAGINE
client.compute().call(...)	compute() sim, call() não	compute().execute(...), submitAsync(...), MapReduce, etc.	TROCA DIRECTA
client.events()	Não	Event Log configurado no cluster; actualmente sinks de log	REIMAGINE
client.services()	Não	Não há Service Grid equivalente nesta API; eventualmente Compute ou serviço externo	REIMAGINE
client.semaphore()	Não	Não há distributed semaphore público	REIMAGINE
client.cluster().nodes()	Sim	Exactamente essa API	TROCA DIRECTA
client.getOrCreateCache(...)	Não	criar tabela via Catalog/SQL com IF NOT EXISTS	TROCA DIRECTA na intenção, mas muda o modelo

Cache → Table

Esta é provavelmente a maior mudança da migração. Em Ignite 3, o equivalente conceptual de key/value data é uma Table com KeyValueView, não IgniteCache/ClientCache. A própria documentação descreve Ignite 3 como tendo migrado a key-value API para Table API. (Apache Ignite)

Por exemplo, algo semelhante a:

java
ClientCache<String, FxRate> cache =
    client.cache("FX_RATE");

FxRate rate = cache.get("EURUSD");

passa conceptualmente para:

java
Table table = client.tables().table("FX_RATE");

KeyValueView<String, FxRate> rates =
    table.keyValueView(String.class, FxRate.class);

FxRate rate = rates.get(null, "EURUSD");

O primeiro argumento null é a transação — null significa executar sem uma transação explícita. A documentação demonstra exactamente KeyValueView.get(), put(), RecordView, POJO mapping, etc. (Apache Ignite)

Locks

cache.lock(key) não tem substituto directo.

Ignite 3 usa locking internamente nas transações read-write, que são SERIALIZABLE: uma operação transacional adquire locks e mantém-nos até commit/rollback. Mas esses locks não são apresentados ao utilizador como java.util.concurrent.locks.Lock, como acontecia no Ignite 2. (Apache Ignite)

Portanto:

java
cache.lock(key)

é REIMAGINE.

Se o vosso código fazia lock → ler/modificar o mesmo dado → unlock, frequentemente pode ser reescrito como uma transação Ignite 3. Se o lock era utilizado como mutex distribuído para proteger uma secção arbitrária de código, então precisam de redesenhar essa coordenação.

Compute

Aqui há funcionalidade real de thin client:

java
client.compute()

existe. Mas não há call(). A API 3.1 apresenta execute, executeAsync, submitAsync, broadcast e MapReduce. (Apache Ignite)

Conceptualmente:

java
ignite.compute().call(...)

torna-se algo do género:

java
client.compute().execute(
    JobTarget.anyNode(client.cluster().nodes()),
    JobDescriptor.builder(MyJob.class).build(),
    argument
);

Portanto eu marcaria Compute = TROCA DIRECTA, embora seja necessária adaptação da API/job model.

Events

Não existe:

java
client.events()

na interface Ignite/IgniteClient. Ignite 3 tem Event Log, mas é outro conceito: os eventos são configurados cluster-wide através de channels e sinks e, na documentação 3.1, o sink suportado é o log. (Apache Ignite)

Se actualmente usam Ignite Events apenas para logging/monitorização, talvez bastante desse código possa simplesmente ser REMOVER.

Se usam listeners Ignite para lógica funcional da aplicação, é REIMAGINE.

Services

client.services() também não existe na API pública 3.1. IgniteClient só herda catalog/cluster/compute/sql/tables/transactions. (Apache Ignite)

Se os vossos IgniteServices eram basicamente “executar código num nó”, Compute pode absorver alguns casos. Se dependiam de cluster singleton, lifecycle, service proxy, deployment permanente, etc., então é REIMAGINE.

Semaphore

Também não existe client.semaphore() nem uma distributed data structures facade equivalente na API pública 3.1. (Apache Ignite)

REIMAGINE — por exemplo com coordenação transacional desenhada especificamente para o caso, ou outro mecanismo externo de coordenação.

Cluster nodes

Este existe exactamente:

java
Collection<ClusterNode> nodes =
    client.cluster().nodes();

Aliás clusterNodes() foi deprecated em 3.1 especificamente a favor de:

java
client.cluster().nodes()

(Apache Ignite)

TROCA DIRECTA.

getOrCreateCache

Não há getOrCreateCache(), porque já não estás a criar caches desta forma.

Em 3.1 podes fazer, por exemplo:

java
client.sql().execute(
    null,
    """
    CREATE TABLE IF NOT EXISTS FX_RATE (
        PAIR VARCHAR PRIMARY KEY,
        RATE DECIMAL
    )
    """
);

ou usar o Catalog Java API:

java
client.catalog().createTable(
    TableDefinition.builder("FX_RATE")
        .ifNotExists()
        .columns(...)
        .primaryKey(...)
        .build()
);

O quick start 3.1 mostra explicitamente client.catalog().createTable(...). (Apache Ignite)

Portanto: não há substituição sintáctica de uma linha, mas há uma substituição bastante clara: Cache provisioning → Table/schema provisioning.

---

4. Existe ignite-spring / Spring Cache para 3.1?

Aqui a resposta necessita de uma distinção importante:

Spring Boot integration para IgniteClient: SIM.
Spring Cache integration equivalente a IgniteClientSpringCacheManager: NÃO para Ignite 3.1.

Há um artefacto oficial 3.1:

xml
<dependency>
    <groupId>org.apache.ignite</groupId>
    <artifactId>spring-boot-starter-ignite-client</artifactId>
    <version>3.1.0</version>
</dependency>

que traz spring-boot-ignite-client-autoconfigure e ignite-client:3.1.0. A proposta oficial da ASF para Spring Boot especifica precisamente auto-configurar um bean IgniteClient através das propriedades ignite.client.*. (Maven Central)

Isto significa que até o nosso IgniteConfig manual pode desaparecer e passar a algo deste género:

properties
ignite.client.addresses=ignite-node-1:10800,ignite-node-2:10800

com:

java
@Autowired
private IgniteClient igniteClient;

Mas isto não é Spring Cache.

A integração antiga:

java
IgniteClientSpringCacheManager

pertence ao ignite-spring-cache-ext da geração Ignite 2. A versão mais recente desse artefacto encontrada (2.0.0) depende explicitamente de:

text
ignite-core:2.16.0
ignite-spring:2.16.0

ou seja, não é uma implementação Spring Cache para Ignite 3.1. (Maven Central)

A própria página de downloads separa essas extensões antigas e identifica a Spring Boot auto-configuration antiga como suporte para Ignite 2.x. (Apache Ignite)

Portanto, para o teu JsonCacheProxyManager:

se ele depende de Spring CacheManager / @Cacheable → classifica como REIMAGINE.

Terás de implementar/adoptar um org.springframework.cache.CacheManager/Cache que por baixo use algo como:

java
IgniteClient
   -> tables()
   -> table(cacheName)
   -> keyValueView(...)

A boa notícia é que a camada provavelmente não precisa de ser enorme, mas não há um IgniteClientSpringCacheManager 3.1 que possas simplesmente trocar no POM.

---

5. O que aconteceu a @QuerySqlField?

Desapareceu no Ignite 3.1.

E a package que tinhas como possibilidade também não está correcta para 3.1. Em Ignite 2 a annotation era:

java
org.apache.ignite.cache.query.annotations.QuerySqlField

(Apache Ignite)

No modelo Ignite 3, SQL deixou de descobrir “queryable fields” de um cache através de @QuerySqlField. O SQL trabalha sobre tabelas e colunas explicitamente definidas no schema.

Ignite 3.1 tem um novo conjunto de annotations em:

java
org.apache.ignite.catalog.annotations

nomeadamente:

java
@Table
@Column
@Id
@Index
@ColumnRef
@Zone

(Apache Ignite)

Por exemplo, algo antigo como:

java
public class Person {
    @QuerySqlField(index = true)
    private String name;
}

não passa para outra annotation chamada QuerySqlField.

Se o schema for definido em Java, seria algo conceptualmente como:

java
@Table(
    indexes = @Index(
        value = "IDX_PERSON_NAME",
        columns = @ColumnRef("NAME")
    )
)
public class Person {

    @Id
    private Integer id;

    @Column("NAME")
    private String name;
}

A documentação explica que @Column é usado para mapear o POJO para a coluna, enquanto @Index, @Table, @Id etc. podem ser usados para definir o próprio schema. (Apache Ignite)

Se criarem a tabela com SQL:

sql
CREATE TABLE PERSON (
    ID INT PRIMARY KEY,
    NAME VARCHAR
);

CREATE INDEX IDX_PERSON_NAME ON PERSON(NAME);

nem sequer precisas de uma annotation para tornar NAME “queryable”. Ela é uma coluna SQL por definição. (Apache Ignite)

Portanto eu classificaria:

@QuerySqlField → REMOVER, se só indicava “este campo pode aparecer em SQL”.

@QuerySqlField(index = true) → TROCA/REIMAGINE, porque o índice deve passar para DDL, @Index ou Catalog API.

---

Resultado para a tua tabela de migração

A leitura da documentação muda bastante o perfil da migração:

Ignite 2	Ignite 3.1	Decisão
IgniteSpringBean	IgniteClient bean / Spring Boot starter	TROCA DIRECTA
IgniteConfiguration no cliente	IgniteClient.builder() / properties	TROCA DIRECTA
client-side SPIs	configuração do cluster/nós	REMOVER do app
IgniteCache / ClientCache CRUD	Table + KeyValueView/RecordView	TROCA DIRECTA para CRUD
explicit cache locks	sem equivalente	REIMAGINE
Compute Grid	Compute API 3	TROCA DIRECTA
Events API/listeners	Event Log, sem client.events()	REIMAGINE/REMOVER
Service Grid	sem equivalente público	REIMAGINE
Semaphore/data structures	sem equivalente público	REIMAGINE
clusterNodes()	cluster().nodes()	TROCA DIRECTA
getOrCreateCache()	Catalog/CREATE TABLE IF NOT EXISTS	TROCA DIRECTA conceptual
Spring Cache Manager	sem equivalente Ignite 3.1	REIMAGINE
@QuerySqlField	schema + @Column/@Index etc.	REMOVER/TROCA

Isto confirma uma coisa importante para estimar o trabalho: a configuração de ligação é muito mais simples, mas a dificuldade da migração está nos usos de Ignite como plataforma distribuída — locks, services, events, semaphores e Spring Cache — e não na criação do IgniteClient.