Яка різниця між JOIN та JOIN FETCH при використанні JPA та Hibernate

Будь ласка, допоможіть мені зрозуміти, де використовувати звичайний ПРИЄДНАЙТЕСЬ та де ПРИЄДНАЙТЕ ПОДОБ.

Наприклад, якщо у нас є ці два запити

FROM Employee emp
JOIN emp.department dep

і

FROM Employee emp
JOIN FETCH emp.department dep

Чи є різниця між ними? Якщо так, то який саме використовувати коли?

У цих двох запитах ви використовуєте JOIN для запиту всіх співробітників, які мають принаймні один відділ.

Але різниця полягає в тому, що в першому запиті ви повертаєте лише службовців для сплячого. У другому запиті ви повертаєте службовців та всі пов'язані з ними відділи.

Отже, якщо ви використовуєте другий запит, вам не потрібно буде робити новий запит, щоб знову потрапити в базу даних, щоб побачити підрозділи кожного співробітника.

Ви можете використовувати другий запит, коли впевнені, що вам знадобиться відділ кожного працівника. Якщо вам не потрібен відділ, використовуйте перший запит.

Я рекомендую прочитати це посилання, якщо вам потрібно застосувати якусь умову WHERE (що вам, мабуть, знадобиться): Як правильно виразити JPQL "приєднатись до отримання" з "де" пунктом як JPA 2 CriteriaQuery?

Оновлення

Якщо ви не користуєтесь, fetchа Департаменти продовжують повертатись, це тому, що ваше відображення між Співробітником та Департаментом (а @OneToMany) встановлено FetchType.EAGER. У цьому випадку будь-який fetchзапит HQL (із запитом чи ні) FROM Employeeпринесе всі відділи. Пам’ятайте, що всі відображення * ToOne ( @ManyToOneі @OneToOne) за замовчуванням є EAGER.

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

Об’єднання "отримання" дозволяє асоціації або колекції значень ініціалізуватися разом із їхніми батьківськими об'єктами за допомогою одного вибору. Це особливо корисно у випадку з колекцією. Це ефективно перекриває зовнішнє об'єднання та ліниві декларації картографічного файлу для асоціацій та колекцій.

це "ПРИЄДНУЙТЕ ФЕТЧ" матиме ефект, якщо ви маєте (fetch = FetchType.LAZY) властивість для колекції всередині сутності (наприклад, нижче).

І це лише ефект методу "коли запит має відбутися". І ви також повинні знати це :

сплячий має два ортогональних поняття: коли відбувається асоціація і як вона виймається. Важливо, щоб ви не переплутали їх. Ми використовуємо функцію для налаштування продуктивності. Ми можемо використовувати ледачий, щоб визначити договір, які дані завжди доступні в будь-якому окремому екземплярі певного класу.

коли вибирається асоціація -> ваш тип "ВИКОНАННЯ"

як це витягнуто -> Приєднатися / вибрати / Підібрати / Пакет

У вашому випадку FETCH матиме ефект лише в тому випадку, якщо у вас є відділ як набір у співробітнику, щось подібне в організації:

@OneToMany(fetch = FetchType.LAZY)
private Set<Department> department;

коли ви використовуєте

FROM Employee emp
JOIN FETCH emp.department dep

ви отримаєте empі emp.dep. коли ви не користуєтеся добутком, ви все одно можете отримати, emp.depале сплячий режим обробить інший вибір до бази даних, щоб отримати цей набір відділу.

тож це лише питання налаштування продуктивності, про те, що ви хочете отримати весь результат (вам це потрібно чи ні) в одному запиті (нетерплячий видобуток), або ви хочете запитувати його останнім, коли вам це потрібно (лінивий вибір).

Використовуйте нетерплячий пошук, коли вам потрібно отримати невеликі дані за допомогою одного вибору (один великий запит). Або скористайтеся ледачим пошуком, щоб запитати, що вам потрібно останнім (багато менших запитів).

використовувати fetch, коли:

• немає великої непотрібної колекції / набору всередині тієї організації, яку ви збираєтеся отримати

• спілкування від сервера додатків до сервера баз даних занадто далеко і потребує тривалого часу

• вам може знадобитися , що збір останнього , коли у вас немає доступу до нього ( за межі від транзакційного методу / класу)

ПРИЄДНАЙТЕСЬ

При використанні JOINпроти асоціацій суб'єктів, JPA генерує JOIN між батьківською сутністю та таблицями дочірньої сутності у створеному операторі SQL.

Отже, беручи свій приклад, виконуючи цей запит JPQL:

FROM Employee emp
JOIN emp.department dep

Hibernate буде генерувати такий оператор SQL:

SELECT emp.*
FROM employee emp
JOIN department dep ON emp.department_id = dep.id

Зауважте, що SELECTпункт SQL містить лише employeeстовпці таблиці, а не departmentті. Для отримання departmentстовпців таблиці нам потрібно використовувати JOIN FETCHзамість JOIN.

ПРИЄДНАЙТЕСЬ ДО ПОДІЙ

Отже, порівняно з JOIN, це JOIN FETCHдозволяє проектувати стовпці таблиці приєднання в SELECTпункті згенерованого оператора SQL.

Отже, у вашому прикладі при виконанні цього запиту JPQL:

FROM Employee emp
JOIN FETCH emp.department dep

Hibernate буде генерувати такий оператор SQL:

SELECT emp.*, dept.*
FROM employee emp
JOIN department dep ON emp.department_id = dep.id

Зауважте, що цього разу departmentвибираються також стовпці таблиці, а не лише ті, що асоціюються з сутністю, переліченою у FROMпункті JPQL.

Крім того, JOIN FETCHце чудовий спосіб вирішити питання LazyInitializationExceptionщодо використання в режимі Hibernate, оскільки ви можете ініціалізувати асоціації об'єктів, використовуючи FetchType.LAZYстратегію отримання, а також основну сутність, яку ви отримуєте.

Якщо у вас встановлено @oneToOneвідображення FetchType.LAZYі ви використовуєте другий запит (оскільки вам потрібно завантажувати об’єкти відділу як частину об'єктів Employee), що робитиме Hibernate, це видасть запити для отримання об’єктів відділу для кожного окремого об'єкта Employee, який він отримує з БД.

Пізніше в коді ви можете отримати доступ до об'єктів Департаменту через службовця відділу до однозначного об'єднання, і Hibernate не видасть жодного запиту для отримання об’єкта Департаменту для даного Співробітника.

Пам'ятайте, Hibernate все ще видає запити, що дорівнює кількості працівників, яких вона отримала. Hibernate видасть однакову кількість запитів в обох вищезазначених запитах, якщо ви хочете отримати доступ до об'єктів відділу всіх об'єктів працівника

Дерік: Я не впевнений у тому, що ви говорите, коли ви не будете використовувати результат, результат буде мати тип: List<Object[ ]>що означає перелік таблиць об'єктів, а не список співробітників.

Object[0] refers an Employee entity 
Object[1] refers a Departement entity 

Якщо ви користуєтеся програмою "Вибір", вибирається лише один вибір, а результат - список "Співробітник" List<Employee> що містить перелік відділень. Це переосмислює ледачу заяву сутності.