Hibernate кидає MultipleBagFetchException - не може одночасно отримати кілька мішків

Hibernate скидає цей виняток під час створення SessionFactory:

org.hibernate.loader.MultipleBagFetchException: не може одночасно отримати кілька пакетів

Це мій тестовий випадок:

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;

}

Як щодо цієї проблеми? Що я можу зробити?

EDIT

Гаразд, проблема, що я маю, полягає в тому, що ще одна "батьківська" сутність знаходиться всередині мого батька, моя реальна поведінка така:

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;

}

Hibernate не любить дві колекції FetchType.EAGER, але це, здається, помилка, я не займаюся незвичайними речами ...

Видалення FetchType.EAGERз Parentабо AnotherParentвирішує проблеми, але мені це потрібно, тому реальне рішення полягає у використанні @LazyCollection(LazyCollectionOption.FALSE)замість FetchType(спасибі Bozho для вирішення).

Я думаю, що з цим повинна впоратися нова версія сплячого режиму (підтримує JPA 2.0). Але в іншому випадку можна обійти це, анотувавши поля колекції за допомогою:

@LazyCollection(LazyCollectionOption.FALSE)

Не забудьте видалити fetchTypeатрибут із @*ToManyпримітки.

Але зауважте, що в більшості випадків а Set<Child>є більш підходящим, ніж List<Child>, тому, якщо вам насправді не потрібно List- ідітьSet

Але нагадайте, що за допомогою наборів ви не усунете нижній декартовий продукт, як описав Влад Міхалча у своїй відповіді !

Просто змініть Listтип на Setтип.

Але нагадайте, що ви не усунете нижній декартовий продукт, як описав Влад Міхалча у своїй відповіді !

Додайте до свого коду примітку @Fetch, специфічну для спячки:

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

Це має виправити проблему, пов’язану із сплячкою помилки HHH-1718

Це питання є повторюваною темою як на StackOverflow, так і на форумі Hibernate, тому я вирішив перетворити відповідь також у статтю .

Зважаючи на те, що у нас є такі суб'єкти:

І ви хочете отримати деякі материнські Postсутності разом із усіма колекціями commentsта tags.

Якщо ви використовуєте кілька JOIN FETCHдиректив:

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();

Спящий режим кине сумнозвісний:

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
]

Зимова сплячка не дозволяє отримати більше одного пакетика, оскільки це призведе до отримання декартового продукту .

Найгірше "рішення"

Тепер ви знайдете безліч відповідей, дописів у блогах, відео чи інших ресурсів, які дозволять використовувати Setзамість цього Listколекцію замість .

Це жахлива порада. Не робіть цього!

Використання Setsзамість цього Listsдозволить MultipleBagFetchExceptionзникнути, але декартовий продукт все одно буде там, що насправді ще гірше, оскільки проблему з ефективністю ви дізнаєтесь задовго після того, як застосували це «виправлення».

Правильне рішення

Ви можете виконати наступний трюк:

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();

У першому запиті JPQL distinctНЕ переходить до оператора SQL. Ось чому ми встановили PASS_DISTINCT_THROUGHнатяк на запит JPA false.

DISTINCT має два значення у JPQL, і тут нам це потрібно для подвоєння посилань на об’єкти Java, повернених getResultListна стороні Java, а не на стороні SQL. Перегляньте цю статтю для отримання більш детальної інформації.

Поки ви отримаєте максимум одну колекцію, використовуючи JOIN FETCH, ви будете добре.

Використовуючи кілька запитів, ви уникнете декартового продукту, оскільки будь-яка інша колекція, окрім першого, вибирається за допомогою вторинного запиту.

Ви можете зробити більше

Якщо ви використовуєте FetchType.EAGERстратегію під час відображення часу @OneToManyабо @ManyToManyасоціацій, ви можете легко закінчити програму a MultipleBagFetchException.

Вам краще переключитися FetchType.EAGERна режим, Fetchype.LAZYоскільки нетерплячий пошук - це жахлива ідея, яка може призвести до критичних проблем з роботою програми .

Висновок

Уникайте FetchType.EAGERта не перемикайтесь Listна Setлише тому, що це зробить сплячку сховатися MultipleBagFetchExceptionпід килимом. Отримайте відразу одну колекцію, і ви будете добре.

Поки ви робите це з тією ж кількістю запитів, що і колекції для ініціалізації, ви все в порядку. Просто не ініціалізуйте колекції в циклі, оскільки це спричинить проблеми запитів N + 1 , які також погані для продуктивності.

Спробувавши кожен варіант опису в цій публікації та інших, я дійшов висновку, що виправлення полягає в наступному.

У кожному місці XToMany @ XXXToMany(mappedBy="parent", fetch=FetchType.EAGER) і безпосередньо після нього

@Fetch(value = FetchMode.SUBSELECT)

Це працювало для мене

Щоб виправити це, просто Setзамість Listвашого вкладеного об'єкта.

@OneToMany
Set<Your_object> objectList;

і не забудьте використовувати fetch=FetchType.EAGER

це спрацює.

Є ще одна концепція CollectionIdв сплячому режимі, якщо ви хочете дотримуватися лише списку.

Але нагадайте, що ви не усунете нижній декартовий продукт, як описав Влад Міхалча у своїй відповіді !

Я знайшов хорошу публікацію в блозі про поведінку Hibernate у подібних об’єктах відображення: http://blog.eyallupu.com/2010/06/hibernate-exception-sim istovremenoly.html

ви можете зберігати списки EAGER у JPA та додавати принаймні до одного анотацію JPA @OrderColumn (із очевидною назвою поля, яке потрібно замовити). Немає потреби в конкретних сплячих анотаціях. Але майте на увазі, що це може створити порожні елементи у списку, якщо вибране поле не має значень, починаючи з 0

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

у дітей тоді слід додати поле orderIndex

Ми спробували Set замість List, і це кошмар: коли ви додаєте два нових об’єкти, equals () та hashCode () не в змозі їх розрізнити! Тому що вони не мають жодного ідентифікатора.

типові інструменти, як Eclipse, генерують такий тип коду з таблиць бази даних:

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

Ви також можете прочитати цю статтю, яка правильно пояснює, наскільки зіпсований JPA / Hibernate. Прочитавши це, я думаю, що це останній раз, коли я використовую будь-яку ОРМ у своєму житті.

Я також зіткнувся з хлопцями, які керують доменом, які в основному кажуть, що ORM - жахлива річ.

Якщо у вас занадто складні об'єкти з колекцією saveral не може бути гарною ідеєю мати їх усіма EAGER fetchType, краще скористайтеся LAZY і коли вам дійсно потрібно завантажити колекції, використовуйте: Hibernate.initialize(parent.child)для отримання даних.

Для мене проблема полягала у вкладенні EAGER витягів .

Одне рішення - встановити вкладені поля на LAZY та використовувати Hibernate.initialize () для завантаження вкладених полів:

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

Зрештою, це сталося, коли у мене було декілька колекцій із FetchType.EAGER, наприклад:

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

Крім того, колекції об’єднувались в одній колоні.

Щоб вирішити цю проблему, я змінив одну з колекцій на FetchType.LAZY, оскільки це було нормально для мого використання.

Удачі! ~ J

Коментуючи Fetchі LazyCollectionінколи, і іноді допомагає запустити проект.

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

Хороша річ у @LazyCollection(LazyCollectionOption.FALSE)тому, що кілька полів із цією анотацією можуть співіснувати, але FetchType.EAGERне можуть, навіть у ситуаціях, коли таке співіснування є законним.

Наприклад, Orderможе мати список OrderGroup(короткий), а також список Promotions(також короткий). @LazyCollection(LazyCollectionOption.FALSE)можуть бути використані на обох без не викликає LazyInitializationExceptionні MultipleBagFetchException.

У моєму випадку я @Fetchвирішив мою проблему, MultipleBacFetchExceptionале потім викликає LazyInitializationExceptionсумнозвісну no Sessionпомилку.

Ви можете використати нову примітку для вирішення цього питання:

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

Насправді значенням за замовчуванням fetch є також FetchType.LAZY.