O Hibernate lança MultipleBagFetchException - não pode buscar simultaneamente vários pacotes

O Hibernate lança essa exceção durante a criação do SessionFactory:

org.hibernate.loader.MultipleBagFetchException: não é possível buscar simultaneamente vários pacotes

Este é o meu caso de teste:

Parent.java

@Entity
public Parent {

 @Id
 @GeneratedValue(strategy=GenerationType.IDENTITY)
 private Long id;

 @OneToMany(mappedBy="parent", fetch=FetchType.EAGER)
 // @IndexColumn(name="INDEX_COL") if I had this the problem solve but I retrieve more children than I have, one child is null.
 private List<Child> children;

}

Child.java

@Entity
public Child {

 @Id
 @GeneratedValue(strategy=GenerationType.IDENTITY)
 private Long id;

 @ManyToOne
 private Parent parent;

}

E esse problema? O que eu posso fazer?

EDITAR

OK, o problema que tenho é que outra entidade "pai" está dentro do meu pai, meu comportamento real é este:

Parent.java

@Entity
public Parent {

 @Id
 @GeneratedValue(strategy=GenerationType.IDENTITY)
 private Long id;

 @ManyToOne
 private AnotherParent anotherParent;

 @OneToMany(mappedBy="parent", fetch=FetchType.EAGER)
 private List<Child> children;

}

AnotherParent.java

@Entity
public AnotherParent {

 @Id
 @GeneratedValue(strategy=GenerationType.IDENTITY)
 private Long id;

 @OneToMany(mappedBy="parent", fetch=FetchType.EAGER)
 private List<AnotherChild> anotherChildren;

}

O Hibernate não gosta de duas coleções FetchType.EAGER, mas isso parece ser um bug, não estou fazendo coisas incomuns ...

Remoção FetchType.EAGERde Parentou AnotherParentresolve o problema, mas eu preciso dele, então verdadeira solução é usar @LazyCollection(LazyCollectionOption.FALSE)em vez de FetchType(graças a Bozho para a solução).

Eu acho que uma versão mais recente do hibernate (com suporte ao JPA 2.0) deve lidar com isso. Caso contrário, você pode contornar os campos da coleção com:

@LazyCollection(LazyCollectionOption.FALSE)

Lembre-se de remover o fetchTypeatributo da @*ToManyanotação.

Mas observe que, na maioria dos casos, a Set<Child>é mais apropriado do que List<Child>, portanto, a menos que você realmente precise de List- vá paraSet

Mas lembre-se de que, com o uso de conjuntos, você não eliminará o Produto Cartesiano subjacente, conforme descrito por Vlad Mihalcea em sua resposta !

Simplesmente mude de um Listtipo para outro Set.

Mas lembre-se de que você não eliminará o Produto Cartesiano subjacente, conforme descrito por Vlad Mihalcea em sua resposta !

Adicione uma anotação @Fetch específica do Hibernate ao seu código:

@OneToMany(mappedBy="parent", fetch=FetchType.EAGER)
@Fetch(value = FetchMode.SUBSELECT)
private List<Child> childs;

Isso deve corrigir o problema relacionado ao bug do Hibernate HHH-1718

Essa pergunta tem sido um tema recorrente no StackOverflow ou no fórum Hibernate, então decidi transformar a resposta em um artigo também.

Considerando que temos as seguintes entidades:

E você deseja buscar algumas Postentidades pai junto com todas as coleções commentse tags.

Se você estiver usando mais de uma JOIN FETCHdiretiva:

List<Post> posts = entityManager
.createQuery(
    "select p " +
    "from Post p " +
    "left join fetch p.comments " +
    "left join fetch p.tags " +
    "where p.id between :minId and :maxId", Post.class)
.setParameter("minId", 1L)
.setParameter("maxId", 50L)
.getResultList();

O Hibernate lançará o infame:

org.hibernate.loader.MultipleBagFetchException: cannot simultaneously fetch multiple bags [
  com.vladmihalcea.book.hpjp.hibernate.fetching.Post.comments,
  com.vladmihalcea.book.hpjp.hibernate.fetching.Post.tags
]

O Hibernate não permite buscar mais de uma bolsa, pois isso geraria um produto cartesiano .

A pior "solução"

Agora, você encontrará muitas respostas, postagens de blog, vídeos ou outros recursos solicitando que você use um em Setvez de um Listpara suas coleções.

Esse é um conselho terrível. Não faça isso!

Usar em Setsvez de Listsfará MultipleBagFetchExceptiondesaparecer, mas o Produto Cartesiano ainda estará lá, o que é ainda pior, pois você descobrirá o problema de desempenho muito depois de aplicar essa "correção".

A solução adequada

Você pode executar o seguinte truque:

List<Post> posts = entityManager
.createQuery(
    "select distinct p " +
    "from Post p " +
    "left join fetch p.comments " +
    "where p.id between :minId and :maxId ", Post.class)
.setParameter("minId", 1L)
.setParameter("maxId", 50L)
.setHint(QueryHints.PASS_DISTINCT_THROUGH, false)
.getResultList();

posts = entityManager
.createQuery(
    "select distinct p " +
    "from Post p " +
    "left join fetch p.tags t " +
    "where p in :posts ", Post.class)
.setParameter("posts", posts)
.setHint(QueryHints.PASS_DISTINCT_THROUGH, false)
.getResultList();

Na primeira consulta JPQL, distinctNÃO vai para a instrução SQL. É por isso que configuramos a PASS_DISTINCT_THROUGHdica de consulta JPA para false.

DISTINCT tem dois significados no JPQL e, aqui, precisamos deduplicar as referências de objetos Java retornadas pelo getResultListlado Java, não pelo lado SQL. Confira este artigo para mais detalhes.

Contanto que você busque no máximo uma coleção usando JOIN FETCH, você ficará bem.

Ao usar várias consultas, você evitará o produto cartesiano, pois qualquer outra coleção, mas a primeira é buscada usando uma consulta secundária.

Há mais que você poderia fazer

Se você estiver usando a FetchType.EAGERestratégia no momento do mapeamento para @OneToManyou @ManyToManyassociações, poderá facilmente terminar com a MultipleBagFetchException.

É melhor mudar de FetchType.EAGERpara, Fetchype.LAZYpois a busca ansiosa é uma péssima idéia que pode levar a problemas críticos de desempenho do aplicativo .

Conclusão

Evite FetchType.EAGERe não mude de Listpara Setapenas porque isso fará com que o Hibernate oculte o MultipleBagFetchExceptionsob o tapete. Busque apenas uma coleção de cada vez, e você ficará bem.

Contanto que você faça isso com o mesmo número de consultas que possui coleções para inicializar, você estará bem. Apenas não inicialize as coleções em um loop, pois isso desencadeará problemas de consulta N + 1 , que também prejudicam o desempenho.

Depois de tentar com todas as opções descritas nessas postagens e em outras, cheguei à conclusão de que a correção é a seguinte.

Em todo lugar XToMany @ XXXToMany(mappedBy="parent", fetch=FetchType.EAGER) e intermediariamente após

@Fetch(value = FetchMode.SUBSELECT)

Isso funcionou para mim

Para corrigi-lo, basta Setsubstituir Listo objeto aninhado.

@OneToMany
Set<Your_object> objectList;

e não se esqueça de usar fetch=FetchType.EAGER

vai funcionar.

Há mais um conceito CollectionIdno Hibernate, se você deseja manter apenas a lista.

Mas lembre-se de que você não eliminará o Produto Cartesiano subjacente, conforme descrito por Vlad Mihalcea em sua resposta !

Encontrei uma boa publicação no blog sobre o comportamento do Hibernate nesse tipo de mapeamento de objetos: http://blog.eyallupu.com/2010/06/hibernate-exception-simultially.html

você pode manter as listas do EAGER do estande na JPA e adicionar a pelo menos uma delas a anotação da JPA @OrderColumn (com obviamente o nome de um campo a ser solicitado). Não há necessidade de anotações de hibernação específicas. Mas lembre-se de que ele pode criar elementos vazios na lista se o campo escolhido não tiver valores começando em 0

 [...]
 @OneToMany(mappedBy="parent", fetch=FetchType.EAGER)
 @OrderColumn(name="orderIndex")
 private List<Child> children;
 [...]

em Filhos, você deve adicionar o campo orderIndex

Tentamos definir em vez de lista e é um pesadelo: quando você adiciona dois novos objetos, equals () e hashCode () não conseguem distinguir os dois! Porque eles não têm identificação.

ferramentas típicas como o Eclipse geram esse tipo de código a partir de tabelas do banco de dados:

@Override
public int hashCode() {
    final int prime = 31;
    int result = 1;
    result = prime * result + ((id == null) ? 0 : id.hashCode());
    return result;
}

Você também pode ler este artigo que explica corretamente como o JPA / Hibernate está bagunçado. Depois de ler isso, acho que é a última vez que uso ORM em minha vida.

Também encontrei caras do Design Orientado a Domínio que basicamente dizem que o ORM é uma coisa terrível.

Quando você tem objetos muito complexos com coleção saveral, não seria uma boa ideia tê-los com o EAGER fetchType, use melhor o LAZY e, quando você realmente precisar carregar as coleções, use: Hibernate.initialize(parent.child)para buscar os dados.

Para mim, o problema era ter aninhados no EAGER .

Uma solução é definir os campos aninhados como LAZY e usar Hibernate.initialize () para carregar os campos aninhados:

x = session.get(ClassName.class, id);
Hibernate.initialize(x.getNestedField());

No final, isso aconteceu quando eu tive várias coleções com o FetchType.EAGER, assim:

@ManyToMany(fetch = FetchType.EAGER, targetEntity = className.class)
@JoinColumn(name = "myClass_id")
@JsonView(SerializationView.Summary.class)
private Collection<Model> ModelObjects;

Além disso, as coleções estavam se juntando na mesma coluna.

Para resolver esse problema, alterei uma das coleções para FetchType.LAZY, pois estava tudo bem no meu caso de uso.

Boa sorte! ~ J

Comentar Fetche LazyCollectionàs vezes ajuda a executar o projeto.

@Fetch(FetchMode.JOIN)
@LazyCollection(LazyCollectionOption.FALSE)

Uma coisa boa @LazyCollection(LazyCollectionOption.FALSE)é que vários campos com esta anotação podem coexistir enquanto FetchType.EAGERnão podem, mesmo nas situações em que tal coexistência é legítima.

Por exemplo, um Orderpode ter uma lista de OrderGroup(uma curta) e uma lista de Promotions(também curta). @LazyCollection(LazyCollectionOption.FALSE)pode ser usado em ambos sem causar LazyInitializationExceptionnenhum MultipleBagFetchException.

No meu caso @Fetch, resolveu meu problema de, MultipleBacFetchExceptionmas depois causa LazyInitializationException, o no Sessionerro infame .

Você pode usar uma nova anotação para resolver isso:

@XXXToXXX(targetEntity = XXXX.class, fetch = FetchType.LAZY)

De fato, o valor padrão da busca também é FetchType.LAZY.