Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

`AbstractKeyValueAdapter` casts to the requested type before `KeyValueTemplate` can skip mismatching values

Abierto
#697 0 comentarios 0 reacciones 1 asignado Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
48/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
java
Área
databases

Línea de trabajo

Read AbstractKeyValueAdapter.get/delete and KeyValueTemplate.findById, then compare MapKeyValueAdapter with RedisKeyValueAdapter. Confirm the behavior through the findById, findAllById, and delete examples, and resolve whether delete should preserve mismatched entries before adding regression coverage.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

type: bug

When a keyspace is shared by a type hierarchy, findById(id, Subtype.class) throws instead of returning Optional.empty() if the stored value is a supertype instance. AbstractKeyValueAdapter.get(id, keyspace, type) calls type.cast(…) on the stored value, so the type check in KeyValueTemplate.findById(…) is never reached.

@KeySpace("persons")
class Person {
	@Id String id;
}

class Employee extends Person {}

KeyValueTemplate template = new KeyValueTemplate(new MapKeyValueAdapter());
template.insert("1", new Person());

template.findAll(Employee.class);       // []
template.findById("1", Employee.class); // UncategorizedKeyValueException caused by ClassCastException

delete(id, keyspace, type) uses the same cast. template.delete("1", Employee.class) removes the Person entry and then throws, so the caller sees a failure although the entry is gone, and no AfterDeleteEvent is published.

Reproduced with MapKeyValueAdapter on main. Before DATAKV-187 the adapter used an unchecked (T) cast, so the mismatching value reached the type check in KeyValueTemplate.findById(…); the switch to type.cast(…) made it throw.

For get(…), returning null when the value is not an instance of the requested type would make findById(…) consistent with findAll(…).

For delete(…), should an entry whose value is not of the requested type be left in place, or is removing it and then throwing acceptable? For reference, RedisKeyValueAdapter.delete(…) calls the typed get(…) first and removes the entry only if that returns a value.

findAllById(…) from #696 goes through the same typed get(…) and currently behaves like findById(…).

Lenguaje dominante
Java
Estrellas
157
Forks
85
Métricas de merge de PR
Sin PR fusionados en 30 d

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de spring-projects/spring-data-keyvalue

Todos los issues de spring-projects/spring-data-keyvalue

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.