Hibernate: когда я должен использовать Cascade.ALL и когда я должен указать их отдельно

Question

Я обычно комментирую свои отношения one-to-many, many-to-many и many-to-one с CascadeType.ALL, потому что они предоставляют мне все необходимые мне функции.Но я чувствую, что это может привести меня к некоторым проблемам в будущем.Можно ли использовать CascadeType.ALL?Что я должен знать и почему я не должен это использовать?

Answer 1

Каскадирование относится к постоянным действиям, в которых один объект распространяется на другие объекты через ассоциацию.

Каскадирование может применяться к различным действиям Hibernate, и обычно оно транзитивно. "cascade = CascadeType ..." атрибута аннотации, определяющей ассоциацию, говорит, какие действия должны каскадироваться для этой ассоциации.

Cascade = "all" означаетприменить все основные типы каскадов.

Начиная с Hibernate 5.3, эти типы:

• "delete" / "remove",
• "detach" / "evict ",
• " слияние ",
• " блокировка ",
• " сохранение ",
• " обновление ",
• "replicate ",
• " save_update "/" update "

(Некоторые из этих имен каскадных типов устарели и / или устарели.)

Есть еще трисоставные типы:

• "all_delete_orphan" - означает то же самое, что и "all", плюс включение удаления объектов, осиротевших каскадом.
• "delete_orphan" - означает "удалить" плюс удаление из-под контроля.
• "none" - означает отсутствие каскадирования.

Answer 2

Что означает CascadeType.ALL и когда мне следует использовать?

CascadeType.ALL - это все операции (PERSIST, MERGE, REMOVE, REFRESH, DETACH), которые распространяются на связанный объект на связанные объекты в контексте постоянства..

Таким образом, этот вопрос носит весьма общий характер. Если вы знаете эти определения, вы можете определить, нужно ли или нет CascadeType.ALL.

ДОКУМЕНТАЦИЯ:

EntityManager имеет API для сохранения новых сущностей, remove (удаление) существующих сущностей, refresh состояние сущности из хранилища данных и merge состояние отсоединенной сущности обратно в контекст постоянства.

Когда EntityManager выполняет вышеуказанные операции, вы можете указать ему автоматически каскадировать операцию для сущностей, содержащихся в постоянном поле, с помощью свойства cascade вашей аннотации метаданных.Этот процесс рекурсивный.Свойство cascade принимает массив значений перечисления CascadeType.

CascadeType.PERSIST : при сохранении сущности также сохраняются сущности, содержащиеся в этом поле.Мы предлагаем либеральное применение этого правила каскада, потому что если EntityManager находит поле, которое ссылается на новую сущность во время сброса, и поле не использует CascadeType.PERSIST, это ошибка.

CascadeType.MERGE : при объединении состояния объекта также объединяются объекты, содержащиеся в этом поле.

CascadeType.REMOVE : при удалении объекта также удаляются объекты, содержащиеся в этом поле.

CascadeType.REFRESH : при обновлении сущности также обновляйте сущности, содержащиеся в этом поле.

CascadeType.DETACH : при отсоединении сущности,также отсоедините сущности, хранящиеся в этом поле.

ССЫЛКИ:

EJB3.0 Спецификация - 2.1.7 Связи сущностей

Apache-openjpa документы JPA обзор мета-каскад

Answer 3

Помимо мнений выше, также хотел бы добавить следующие моменты.С точки зрения ООП, мы должны думать с точки зрения композиции против агрегации.В java нет ничего, что могло бы обеспечить строгие отношения между родителем и дочерним элементом в отличие от БД с использованием ключей FK.

Концептуально опция CASCADE в hibernate заставляет нас поддерживать эти строгие отношения.

Answer 4

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

1. Если ваша таблица имеет несколько ссылок на другую таблицу, и сохраняющиеся данные в одной таблице должны каскадировать данные на все зависимые таблицы, тогда в этом сценарии вы должны использовать CascadeType.ALL Например:

EmployeeEntity.java

@Entity
@Table(name = "Employee")
public class EmployeeEntity implements Serializable
{
    private static final long serialVersionUID = -1798070786993154676L;
    @Id
    @Column(name = "ID", unique = true, nullable = false)
    private Integer           employeeId;
    @Column(name = "FIRST_NAME", unique = false, nullable = false, length = 100)
    private String            firstName;
    @Column(name = "LAST_NAME", unique = false, nullable = false, length = 100)
    private String            lastName;

    @OneToMany(cascade=CascadeType.ALL, fetch = FetchType.LAZY)
    @JoinColumn(name="EMPLOYEE_ID")
    private Set<AccountEntity> accounts;

    //Getters and Setters Ommited
}

AccountEntity.java

@Entity
@Table(name = "Account")
public class AccountEntity implements Serializable
{
    private static final long serialVersionUID = 1L;
    @Id
    @Column(name = "ID", unique = true, nullable = false)
    @GeneratedValue(strategy = GenerationType.SEQUENCE)
    private Integer           accountId;
    @Column(name = "ACC_NO", unique = false, nullable = false, length = 100)
    private String            accountNumber;

    @OneToOne (mappedBy="accounts",  fetch = FetchType.LAZY)
    private EmployeeEntity employee;

}

Посмотрите на приведенный выше исходный код для EmployeeEntity.java.Он определяет «cascade = CascadeType.ALL» и, по сути, означает, что любые изменения, произошедшие в EmployeeEntity, должны каскадироваться и в AccountEntity.Если вы сохраните сотрудника, все связанные учетные записи также будут сохранены в базе данных.Если вы удалите сотрудника, то все учетные записи, связанные с этим сотрудником, также будут удалены.Достаточно просто.

Но что, если мы хотим каскадировать только операции сохранения, а не операции удаления.Затем нам нужно четко указать это с помощью приведенного ниже кода.

@OneToMany(cascade=CascadeType.PERSIST, fetch = FetchType.LAZY)
@JoinColumn(name="EMPLOYEE_ID")
private Set<AccountEntity> accounts;

В JPA нет стандартного каскадного типа.По умолчанию никакие операции не каскадируются.