Herança JPA @EntityGraph inclui associações opcionais de subclasses

Dado o modelo de domínio a seguir, quero carregar todos os Answers, incluindo seus Values e seus respectivos sub-filhos, e colocá-los em um AnswerDTOpara depois converter para JSON. Eu tenho uma solução funcional, mas ela sofre com o problema N + 1 do qual quero me livrar usando um ad-hoc @EntityGraph. Todas as associações estão configuradas LAZY.

@Query("SELECT a FROM Answer a")
@EntityGraph(attributePaths = {"value"})
public List<Answer> findAll();

Usando um ad-hoc @EntityGraphno Repositorymétodo, posso garantir que os valores sejam pré-buscados para impedir N + 1 na Answer->Valueassociação. Enquanto meu resultado é bom, há outro problema N + 1, devido ao carregamento lento da selectedassociação dos MCValues.

Usando isto

@EntityGraph(attributePaths = {"value.selected"})

falha, porque o selectedcampo é obviamente apenas parte de algumas das Valueentidades:

Unable to locate Attribute  with the the given name [selected] on this ManagedType [x.model.Value];

Como posso dizer à JPA que apenas tente buscar a selectedassociação caso o valor seja a MCValue? Eu preciso de algo parecido optionalAttributePaths.

Você só pode usar um EntityGraphse o atributo de associação fizer parte da superclasse e por isso também fizer parte de todas as subclasses. Caso contrário, EntityGraphsempre falhará com o Exceptionque você recebe atualmente.

A melhor maneira de evitar o problema de seleção do N + 1 é dividir sua consulta em duas consultas:

A primeira consulta busca as MCValueentidades usando um EntityGraphpara buscar a associação mapeada pelo selectedatributo. Após essa consulta, essas entidades são armazenadas no cache do 1º nível do Hibernate / no contexto de persistência. O Hibernate os usará quando processar o resultado da 2ª consulta.

@Query("SELECT m FROM MCValue m") // add WHERE clause as needed ...
@EntityGraph(attributePaths = {"selected"})
public List<MCValue> findAll();

A 2ª consulta busca a Answerentidade e usa um EntityGraphpara também buscar as Valueentidades associadas . Para cada Valueentidade, o Hibernate instanciará a subclasse específica e verificará se o cache do 1º nível já contém um objeto para essa combinação de classe e chave primária. Se for esse o caso, o Hibernate usa o objeto do cache do 1º nível em vez dos dados retornados pela consulta.

@Query("SELECT a FROM Answer a")
@EntityGraph(attributePaths = {"value"})
public List<Answer> findAll();

Como já buscamos todas as MCValueentidades com as selectedentidades associadas , agora obtemos Answerentidades com uma valueassociação inicializada . E se a associação contiver uma MCValueentidade, sua selectedassociação também será inicializada.

Não sei o que o Spring-Data está fazendo lá, mas para fazer isso, você geralmente precisa usar o TREAToperador para poder acessar a sub-associação, mas a implementação para esse Operador é bastante complicada. O Hibernate suporta o acesso implícito à propriedade de subtipos, o que você precisaria aqui, mas aparentemente o Spring-Data não pode lidar com isso corretamente. Eu posso recomendar que você dê uma olhada no Blaze-Persistence Entity-Views , uma biblioteca que funciona sobre a JPA que permite mapear estruturas arbitrárias em relação ao seu modelo de entidade. Você pode mapear seu modelo de DTO de uma maneira segura, além da estrutura de herança. As visualizações de entidade para o seu caso de uso podem ter esta aparência

@EntityView(Answer.class)
interface AnswerDTO {
  @IdMapping
  Long getId();
  ValueDTO getValue();
}
@EntityView(Value.class)
@EntityViewInheritance
interface ValueDTO {
  @IdMapping
  Long getId();
}
@EntityView(TextValue.class)
interface TextValueDTO extends ValueDTO {
  String getText();
}
@EntityView(RatingValue.class)
interface RatingValueDTO extends ValueDTO {
  int getRating();
}
@EntityView(MCValue.class)
interface TextValueDTO extends ValueDTO {
  @Mapping("selected.id")
  Set<Long> getOption();
}

Com a integração de dados do Spring fornecida pelo Blaze-Persistence, você pode definir um repositório como este e usar diretamente o resultado

@Transactional(readOnly = true)
interface AnswerRepository extends Repository<Answer, Long> {
  List<AnswerDTO> findAll();
}

Ele irá gerar uma consulta HQL que seleciona exatamente o que você mapeou no AnswerDTOqual é algo como o seguinte.

SELECT
  a.id, 
  v.id,
  TYPE(v), 
  CASE WHEN TYPE(v) = TextValue THEN v.text END,
  CASE WHEN TYPE(v) = RatingValue THEN v.rating END,
  CASE WHEN TYPE(v) = MCValue THEN s.id END
FROM Answer a
LEFT JOIN a.value v
LEFT JOIN v.selected s

Meu projeto mais recente usou o GraphQL (o primeiro para mim) e tivemos um grande problema com as consultas N + 1 e tentando otimizar as consultas para ingressar em tabelas somente quando necessárias. Eu encontrei Cosium / spring-data-jpa-entity-graph insubstituível. Ele estende JpaRepositorye adiciona métodos para passar um gráfico de entidade para a consulta. Em seguida, você pode criar gráficos de entidade dinâmicos em tempo de execução para adicionar uniões esquerdas para apenas os dados necessários.

Nosso fluxo de dados é mais ou menos assim:

1. Receber solicitação do GraphQL
2. Analise a solicitação GraphQL e converta na lista de nós do gráfico de entidade na consulta
3. Crie um gráfico de entidade a partir dos nós descobertos e passe para o repositório para execução

Para resolver o problema de não incluir nós inválidos no gráfico da entidade (por exemplo, __typenamedo graphql), criei uma classe de utilitário que lida com a geração do gráfico da entidade. A classe de chamada passa no nome da classe para a qual está gerando o gráfico, que valida cada nó no gráfico com relação ao metamodelo mantido pelo ORM. Se o nó não estiver no modelo, ele será removido da lista de nós do gráfico. (Essa verificação precisa ser recursiva e verificar cada criança também)

Antes de descobrir isso, tentei projeções e todas as alternativas recomendadas nos documentos do Spring JPA / Hibernate, mas nada parecia resolver o problema com elegância ou pelo menos com uma tonelada de código extra

Editado após o seu comentário:

Peço desculpas, não subestimei seu problema na primeira rodada, seu problema ocorre na inicialização dos dados da primavera, não apenas quando você tenta chamar o findAll ().

Portanto, agora você pode navegar pelo exemplo completo que pode ser obtido no meu github: https://github.com/bdzzaid/stackoverflow-java/blob/master/jpa-hibernate/

Você pode facilmente reproduzir e corrigir seu problema neste projeto.

De fato, os dados do Spring e o hibernate não são capazes de determinar o gráfico "selecionado" por padrão e você precisa especificar a maneira de coletar a opção selecionada.

Então, primeiro, você deve declarar o NamedEntityGraphs da classe Answer

Como você pode ver, há dois NamedEntityGraph para o valor do atributo da classe Answer

• O primeiro para todos os Value sem relação específica para carregar

• O segundo para o valor específico de escolha múltipla . Se você remover este, você reproduzirá a exceção.

Segundo, você precisa estar em um contexto transacional answerRepository.findAll () se quiser buscar dados no tipo LAZY

@Entity
@Table(name = "answer")
@NamedEntityGraphs({
    @NamedEntityGraph(
            name = "graph.Answer", 
            attributeNodes = @NamedAttributeNode(value = "value")
    ),
    @NamedEntityGraph(
            name = "graph.AnswerMultichoice",
            attributeNodes = @NamedAttributeNode(value = "value"),
            subgraphs = {
                    @NamedSubgraph(
                            name = "graph.AnswerMultichoice.selected",
                            attributeNodes = {
                                    @NamedAttributeNode("selected")
                            }
                    )
            }
    )
}
)
public class Answer
{

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(updatable = false, nullable = false)
    private int id;

    @OneToOne(cascade = CascadeType.ALL)
    @JoinColumn(name = "value_id", referencedColumnName = "id")
    private Value value;
// ..
}