Изучаем Java EE 7 - [89]

Удаление сущностей-сирот

Изолированные сущности нежелательны, поскольку они приводят к тому, что в базе данных есть строки, на которые не ссылается какая-либо другая таблица, при этом они лишены средств доступа. При использовании JPA вы можете проинформировать поставщика постоянства о необходимости автоматически удалять такие сущности или каскадировать операцию удаления. Если целевая сущность (Address) находится в частном владении источника (Customer), подразумевая, что целью никогда не может владеть несколько источников, а этот источник окажется удален приложением, то поставщик должен будет удалить и цель.

Ассоциации, которые определены как «один к одному» или «один ко многим», поддерживают использование параметра orphanRemoval. Чтобы включить этот параметр в пример, взглянем на то, как добавить элемент orphanRemoval=true в аннотацию @OneToOne (листинг 6.11).

Листинг 6.11. Сущность Customer и удаление изолированной сущности Address

@Entity
public class Customer {
··@Id @GeneratedValue
··private Long id;
··private String firstName;
··private String lastName;
··private String email;
··@OneToOne (fetch = FetchType.LAZY, orphanRemoval=true)
··private Address address;
··// Конструкторы, геттеры, сеттеры
}

При таком отображении код, приведенный в листинге 6.10, автоматически удалит сущность Address, если окажется удалена сущность Customer либо если связь будет разорвана (при присвоении атрибуту address значения null или удалении дочерней сущности из коллекции при связи «один ко многим»). Операция удаления выполняется во время операции сброса (когда имеет место фиксация транзакции).

Синхронизация с базой данных

До настоящего момента синхронизация с базой данных осуществлялась во время фиксации. Менеджер сущностей является кэшем первого уровня, ожидающим фиксации транзакции, чтобы сбросить информацию в базу данных. Но что будет, если потребуется вставить Customer и Address?

tx.begin();
em.persist(customer);
em.persist(address);
tx.commit();

Всем ожидаемым изменениям требуется SQL-оператор. В данном случае два оператора insert генерируются и становятся постоянными, только когда происходит фиксация транзакции в базе данных. Для большинства приложений этой автоматической синхронизации данных будет достаточно. Хотя неизвестно, в какой именно момент времени поставщик на самом деле сбрасывает изменения в базу данных, вы можете быть уверены, что это случится, когда произойдет фиксация транзакции. База данных синхронизируется с сущностями в контексте постоянства, однако данные могут быть сброшены (flush) явным образом в базу либо сущности могут быть обновлены с использованием информации из базы (refresh). Если данные будут сброшены в базу данных в определенный момент, а позднее в коде приложение вызовет метод rollback(), то сброшенные данные будут изъяты из базы.

Сброс сущности. С помощью метода EntityManager.flush() поставщика постоянства можно явным образом заставить сбрасывать данные в базу, но не будет фиксации транзакции. Это позволяет разработчику вручную инициировать тот же самый процесс, который менеджер сущностей использует внутренне для сброса контекста постоянства.

tx.begin();
em.persist(customer);
em.flush();
em.persist(address);
tx.commit();

В приведенном коде можно отметить две любопытные вещи. Первая заключается в том, что em.flush() не станет дожидаться фиксации транзакции и заставит поставщика сбросить контекст постоянства. Оператор insert будет сгенерирован и выполнен при сбросе. Вторая вещь состоит в том, что этот код не будет работать из-за ограничения целостности. Без явного сброса менеджер сущностей станет кэшировать все изменения, а также упорядочивать и последовательно вносить их в базу данных. При явном сбросе будет выполнен оператор insert в отношении CUSTOMER, однако ограничение целостности в случае с внешним ключом ADDRESS окажется нарушено (столбец ADDRESS_FK в CUSTOMER). Это приведет к откату транзакции. Откат также произойдет в случае с уже сброшенными данными. Явные сбросы следует использовать осторожно и только при необходимости.

Обновление сущности. Метод refresh() применяется для синхронизации данных в направлении, противоположном сбросу, то есть он перезаписывает текущее состояние сущности, которая находится под управлением, с использованием данных в таком виде, в каком они присутствуют в базе данных. Типичный случай — когда вы используете метод EntityManager.refresh() для отмены изменений, внесенных в сущность только в памяти. Фрагмент варианта тестирования, который приведен в листинге 6.12, обеспечивает поиск Customer по идентификатору, изменение значения его firstName и отмену этого изменения с помощью метода refresh().

Листинг 6.12. Обновление сущности Customer из базы данных

Customer customer = em.find(Customer.class, 1234L)
assertEquals(customer.getFirstName(), "Энтони");
customer.setFirstName("Уильям");
em.refresh(customer);
assertEquals(customer.getFirstName(), "Энтони");");

Содержимое контекста постоянства

В контексте постоянства содержатся сущности, которые находятся под управлением. Используя интерфейс EntityManager, вы можете проверить, находится ли сущность под управлением, отсоединить ее или очистить контекст постоянства от всех сущностей.