Como o JPA orphanRemoval = true difere da cláusula ON DELETE CASCADE DML

Estou um pouco confuso sobre o orphanRemovalatributo JPA 2.0 .

Acho que percebo que é necessário quando uso as ferramentas de geração de banco de dados do meu provedor de JPA para criar o DDL do banco de dados subjacente para ter uma ON DELETE CASCADErelação específica.

No entanto, se o banco de dados existe e já possui uma ON DELETE CASCADErelação, isso não é suficiente para fazer a exclusão da exclusão em cascata? O que o orphanRemovalfaz além disso?

Felicidades

orphanRemovalnão tem nada a ver com ON DELETE CASCADE.

orphanRemovalé uma coisa totalmente específica para ORM . Marca a entidade "filho" a ser removida quando não é mais referenciada da entidade "pai", por exemplo, quando você remove a entidade filho da coleção correspondente da entidade pai.

ON DELETE CASCADEé uma coisa específica do banco de dados , ela exclui a linha "filho" no banco de dados quando a linha "pai" é excluída.

Um exemplo tomado aqui :

Quando um Employeeobjeto de entidade é removido, a operação de remoção é conectada em cascata ao Addressobjeto de entidade referenciado . A este respeito, orphanRemoval=truee cascade=CascadeType.REMOVEsão idênticos, e se orphanRemoval=truefor especificado, CascadeType.REMOVEé redundante.

A diferença entre as duas configurações está na resposta à desconexão de um relacionamento. Por exemplo, como ao definir o campo de endereço para nullou para outro Addressobjeto.

• Se orphanRemoval=truefor especificado, a Addressinstância desconectada será removida automaticamente. Isso é útil para limpar objetos dependentes (por exemplo Address) que não deveriam existir sem uma referência de um objeto proprietário (por exemplo Employee).

• Se apenas cascade=CascadeType.REMOVEfor especificado, nenhuma ação automática será executada, pois desconectar um relacionamento não é uma operação de remoção.

Para evitar referências pendentes como resultado da remoção órfã, esse recurso deve ser ativado apenas para campos que contêm objetos dependentes particulares não compartilhados.

Espero que isso torne mais claro.

No momento em que você remover uma entidade filha da coleção, você também removerá essa entidade filha do banco de dados. orphanRemoval também implica que você não pode mudar de pai; se houver um departamento que tenha funcionários, depois de removê-lo para colocá-lo em outro departamento, você inadvertidamente removerá esse funcionário do banco de dados em liberação / confirmação (o que ocorrer primeiro). O moral é definir orphanRemoval como true, desde que você tenha certeza de que os filhos desse pai não migrarão para um pai diferente durante toda a sua existência. A ativação do orphanRemoval também adiciona REMOVE automaticamente à lista em cascata.

O mapeamento JPA equivalente para o DDL ON DELETE CASCADEé cascade=CascadeType.REMOVE. Remoção órfã significa que as entidades dependentes são removidas quando o relacionamento com a entidade "pai" é destruído. Por exemplo, se um filho for removido de um @OneToManyrelacionamento sem removê-lo explicitamente no gerenciador de entidades.

A diferença é:
- orphanRemoval = true: a entidade "Filho" é removida quando não é mais referenciada (seu pai não pode ser removido).
- CascadeType.REMOVE: A entidade "Filho" é removida apenas quando o "Pai" é removido.

Como essa é uma pergunta muito comum, escrevi este artigo , no qual essa resposta se baseia.

Transições de estado da entidade

O JPA converte transições de estado da entidade para instruções SQL, como INSERT, UPDATE ou DELETE.

Quando você é persistuma entidade, está agendando a instrução INSERT para ser executada quando EntityManagerfor liberada, automática ou manualmente.

quando você é removeuma entidade, está agendando a instrução DELETE, que será executada quando o contexto de persistência for liberado.

Transições de estado da entidade em cascata

Por conveniência, o JPA permite propagar transições de estado de entidade de entidades pai para filho filho.

Portanto, se você tem uma Postentidade pai que tem uma @OneToManyassociação com a PostCommententidade filho:

A commentscoleção na Postentidade é mapeada da seguinte maneira:

@OneToMany(
    mappedBy = "post", 
    cascade = CascadeType.ALL,
    orphanRemoval = true
)
private List<Comment> comments = new ArrayList<>();

CascadeType.ALL

O cascadeatributo informa ao provedor JPA para passar a transição do estado da entidade da entidade pai Postpara todas as PostCommententidades contidas na commentscoleção.

Portanto, se você remover a Postentidade:

Post post = entityManager.find(Post.class, 1L);
assertEquals(2, post.getComments().size());

entityManager.remove(post);

O provedor JPA removerá a PostCommententidade primeiro e, quando todas as entidades filhas forem excluídas, a Postentidade também será excluída :

DELETE FROM post_comment WHERE id = 1
DELETE FROM post_comment WHERE id = 2

DELETE FROM post WHERE id = 1

Remoção de órfãos

Quando você define o orphanRemovalatributo como true, o provedor JPA agendará uma removeoperação quando a entidade filha for removida da coleção.

Então, no nosso caso,

Post post = entityManager.find(Post.class, 1L);
assertEquals(2, post.getComments().size());

PostComment postComment = post.getComments().get(0);
assertEquals(1L, postComment.getId());

post.getComments().remove(postComment);

O provedor JPA removerá o post_commentregistro associado, pois a PostCommententidade não é mais referenciada na commentscoleção:

DELETE FROM post_comment WHERE id = 1

EM EXCLUIR CASCADE

O ON DELETE CASCADEé definido no nível FK:

ALTER TABLE post_comment 
ADD CONSTRAINT fk_post_comment_post_id 
FOREIGN KEY (post_id) REFERENCES post 
ON DELETE CASCADE;

Depois de fazer isso, se você excluir uma postlinha:

DELETE FROM post WHERE id = 1

Todas as post_commententidades associadas são removidas automaticamente pelo mecanismo de banco de dados. No entanto, isso pode ser uma operação muito perigosa se você excluir uma entidade raiz por engano.

Conclusão

A vantagem do JPA cascadee das orphanRemovalopções é que você também pode se beneficiar do bloqueio otimista para evitar atualizações perdidas .

Se você usar o mecanismo de cascata JPA, não precisará usar o nível DDL ON DELETE CASCADE, o que pode ser uma operação muito perigosa se você remover uma entidade raiz que possui muitas entidades filhas em vários níveis.

Para mais detalhes sobre este tópico, consulte este artigo .

Resposta @ GaryK é absolutamente ótimo, eu passei uma hora procurando uma explicação orphanRemoval = truevs CascadeType.REMOVEe isso me ajudou a entender.

Resumindo: orphanRemoval = truefunciona idêntico como CascadeType.REMOVE SOMENTE SE estamos excluindo object ( entityManager.delete(object)) e queremos que os objetos childs sejam removidos também.

Em situações completamente diferentes, quando buscamos alguns dados como List<Child> childs = object.getChilds()e removemos um child ( entityManager.remove(childs.get(0)) usando orphanRemoval=true, a entidade correspondente childs.get(0)será excluída do banco de dados.

A remoção de órfãos tem o mesmo efeito que ON DELETE CASCADE no seguinte cenário: - Digamos que tenhamos um relacionamento simples de muitos para um entre a entidade estudantil e uma entidade guia, em que muitos alunos podem ser mapeados para o mesmo guia e, no banco de dados, temos um relação de chave estrangeira entre a tabela Student e Guide, de forma que a tabela student tenha id_guide como FK.

    @Entity
    @Table(name = "student", catalog = "helloworld")
    public class Student implements java.io.Serializable {
     @Id
     @GeneratedValue(strategy = IDENTITY)
     @Column(name = "id")
     private Integer id;

    @ManyToOne(cascade={CascadeType.PERSIST,CascadeType.REMOVE})
    @JoinColumn(name = "id_guide")
    private Guide guide;

// A entidade pai

    @Entity
    @Table(name = "guide", catalog = "helloworld")
    public class Guide implements java.io.Serializable {

/**
 * 
 */
private static final long serialVersionUID = 9017118664546491038L;

@Id
@GeneratedValue(strategy = IDENTITY)
@Column(name = "id", unique = true, nullable = false)
private Integer id;

@Column(name = "name", length = 45)
private String name;

@Column(name = "salary", length = 45)
private String salary;


 @OneToMany(mappedBy = "guide", orphanRemoval=true) 
 private Set<Student> students = new  HashSet<Student>(0);

Nesse cenário, o relacionamento é tal que a entidade estudantil é o proprietário do relacionamento e, como tal, precisamos salvar a entidade estudantil para manter o gráfico inteiro do objeto, por exemplo

    Guide guide = new Guide("John", "$1500");
    Student s1 = new Student(guide, "Roy","ECE");
    Student s2 = new Student(guide, "Nick", "ECE");
    em.persist(s1);
    em.persist(s2);

Aqui estamos mapeando o mesmo guia com dois objetos de alunos diferentes e, como o CASCADE.PERSIST é usado, o gráfico de objetos será salvo como abaixo na tabela do banco de dados (MySql no meu caso)

Tabela do ALUNO: -

ID Nome Departamento Id_Guide

1 Roy ECE 1

2 Nick ECE 1

Tabela GUIA: -

ID NAME Salário

1 João $ 1500

e agora, se eu quiser remover um dos alunos, usando

      Student student1 = em.find(Student.class,1);
      em.remove(student1);

e quando um registro de aluno é removido, o registro de guia correspondente também deve ser removido, é aí que o atributo CASCADE.REMOVE na entidade Student entra em cena e o que faz é: remove o aluno com o identificador 1, bem como o objeto de guia correspondente (identificador 1) Mas neste exemplo, há mais um objeto de aluno que é mapeado para o mesmo registro de guia e, a menos que usemos o atributo orphanRemoval = true na Entidade de guia, o código de remoção acima não funcionará.