Solucionado (ver solução)
Solucionado
(ver solução)
3
respostas

Transient ou Detached?

Primeiro exemplo:

Conta conta = new Conta();
conta.setId(1);
conta.setTitular("Leonardo");
// aqui
entityManager.persist(conta);

Segundo Exemplo:

Conta conta = new Conta();
conta.setTitular("Leonardo");
// aqui
entityManager.persist(conta);

A única diferença entre o primeiro exemplo e o segundo é a adição da Primary Key (ID). Por que o estado do primeiro exemplo é Detached e o do segundo é Transient?

O estado Transient significa que ainda não foi "Managed" pela aplicação, desta forma o primeiro exemplo não deveria ser Transient também?

Estou utilizando o banco Oracle, e minha Primary Key não se utiliza do auto increment, desta forma tenho que setar manualmente o ID, e não vejo motivo do estado ser "Detached" por conta disso.

3 respostas

Bom dia Giovane, se você setar o campo que é seu @Id, com algum valor, mesmo não tendo sido persistido, este já não é mais considerado transient, por isso fica detached

Guilherme, bom dia!

Hoje realizei um teste aqui com o método remove, aí consegui reproduzir o erro detached. Com o persist, no primeiro exemplo ele dá erro de constraint violation, pois não há como persistir novamente com o mesmo ID, por isso não consigo ver o erro detached.

A única observação é que o o @Id tem que existir no banco, se não ele continua como Transient:

nov 14, 2017 7:29:18 AM org.hibernate.event.internal.DefaultDeleteEventListener deleteTransientEntity
INFO: HHH000114: Handling transient entity in delete processing

Então o primeiro exemplo só seria Detached se o @Id existisse no banco, e Transient caso contrário? Podemos afirmar isso?

DefaultDeleteEventListener - onDelete - GitHub

ForeignKeys - isTransient - GitHub

solução!

Acredito que podemos sim afirmar isso.

Inclusive no curso JAVA E JPA: PERSISTA SEUS OBJETOS COM A JPA2 E HIBERNATE, no minuto 2:04 da Aula 03, Tópico "Conhecendo o estado Detached", o professor afirma:

" - A característica Transient é NUNCA ter sido gerenciada pelo banco."