Dado el siguiente modelo de dominio, quiero cargar todos los correos Answer
electrónicos incluidos sus Value
correos electrónicos y sus respectivos hijos secundarios y ponerlos en un AnswerDTO
para luego convertirlos a JSON. Tengo una solución que funciona pero sufre del problema N + 1 del que quiero deshacerme usando un ad-hoc @EntityGraph
. Todas las asociaciones están configuradas LAZY
.
@Query("SELECT a FROM Answer a")
@EntityGraph(attributePaths = {"value"})
public List<Answer> findAll();
Usando un ad-hoc @EntityGraph
en el Repository
método, puedo asegurarme de que los valores se obtienen previamente para evitar N + 1 en la Answer->Value
asociación. Si bien mi resultado está bien, hay otro problema de N + 1, debido a la carga lenta de la selected
asociación del MCValue
s.
Usando esto
@EntityGraph(attributePaths = {"value.selected"})
falla, porque el selected
campo es, por supuesto, solo parte de algunas de las Value
entidades:
Unable to locate Attribute with the the given name [selected] on this ManagedType [x.model.Value];
¿Cómo puedo decirle a JPA que solo intente buscar la selected
asociación en caso de que el valor sea a MCValue
? Necesito algo así optionalAttributePaths
.
selected
las respuestas que tienen unMCValue
. No me gustó que esto requeriría un bucle adicional y tendría que administrar la asignación entre los conjuntos de datos. Me gusta tu idea de explotar el caché de Hibernate para esto. ¿Puede explicar qué tan seguro (en términos de consistencia) es confiar en el caché para contener los resultados? ¿Funciona esto cuando las consultas se realizan en una transacción? Tengo miedo de los errores de inicialización diferidos esporádicos y difíciles de detectar.