APP:Quando escolher Associação Multivalorada vs.Mapeamento de coleção de elementos
Pergunta
Gostaria de entender melhor as diferenças entre
(1) um tradicional Relacionamento/Associação Multivalorada
@Entity -> @OneToMany -> @Entity
e
(2) a APP2 Coleção de tipos incorporáveis (e básicos)
@Entity -> @ElementCollection -> @Embeddable
Vejo as diferenças sintáticas, mas me pergunto se também existem implicações de desempenho.Nos bastidores, a implementação do banco de dados é muito semelhante.
Intuitivamente, eu normalmente usaria o @ElementCollection
para cenários de composição.Mas mesmo isso parece muito semelhante CascadeType=DELETE
.
Estou perdendo a essência aqui?Um é mais eficiente que o outro para determinados fins?
Obrigado, J.
Solução
Intuitivamente, eu normalmente usaria @ElementCollection para cenários de composição.Mas mesmo isso parece muito semelhante a CascadeType=DELETE
Eles são semelhantes, com algumas pequenas diferenças.O Coleção de Elementos página do Persistência Java O wikibook resume muito bem:
Coleções Embedded
Um
ElementCollection
O mapeamento pode ser usado para definir uma coleção deEmbeddable
objetos.Este não é um uso típico deEmbeddable
objetos como os objetos não são integrado na tabela do objeto de origem, mas armazenada em um tabela de coleta separada.Isso é semelhante a umOneToMany
, exceto o O objeto de destino é umEmbeddable
em vez de de umEntity
.Isso permite coletas de objetos simples para ser facilmente definido, sem a necessidade do simples objetos para definir umId
ouManyToOne
mapeamento inverso.ElementCollection
poder também substitua os mapeamentos ou tabela para sua coleção, para que você possa ter várias entidades fazem referência ao mesmoEmbeddable
classe, mas tem cada loja seus objetos dependentes em um separado mesa.As limitações do uso de um
ElementCollection
em vez de umOneToMany
é que os objetos de destino não pode ser consultado, persistente, mesclado independentemente de seu objeto pai.Eles são estritamente privados objetos (dependentes), o mesmo que umEmbedded
mapeamento.O deles não écascade
opção em umElementCollection
, o os objetos de destino são sempre persistentes, mesclado, removido com seu pai.ElementCollection
ainda pode usar um tipo de busca e padrões paraLAZY
o o mesmo que outros mapeamentos de coleção.
Veja também
Outras dicas
A especificação JPA é clara
Os incorporáveis não podem ser consultados, persistidos ou mesclados independentemente de seu objeto pai. Eles são objetos estritamente de propriedade privada (dependentes)
Você deveria usar com cuidado porque sua vida útil é limitado pela vida útil da instância da entidade proprietária. Portanto, se você persistir/mesclar/remover sua instância de entidade proprietária, todos os seus incorporáveis as instâncias serão persistidas/mescladas/removidas
Suponha que você faça algo como
/**
* Let's suppose owning contains SIX embeddables instances
*/
Owning owning = manager.find(Owining.class, owningId);
Então sua modificação apenas sua entidade proprietária na camada de visualização e envie suas alterações.Você recupera sua entidade proprietária usando
/**
* Usually your web framework Takes care of binding your submitted data
*/
Owning owning = new Owning();
owning.setProperty(request.getParameter("property"));
Então você pode mesclar seus dados enviados e você pensa suas instâncias incorporáveis são armazenados no banco de dados ainda.Bem vamos ver
Como mostrado acima você (ou sua estrutura da web) acabou de recuperar Propriedades proprietárias, certo ???Então seu owning.getElementList() está vazia.Porque owning.getElementList() está vazio, JPA removerá todas as suas instâncias incorporáveis.Mantenha isso em mente.
Geralmente uma classe incorporável não tem relacionamento com outra entidade que não seja sua entidade proprietária.E ao usar um conjunto de incorporáveis, JPA sempre selecione antes de salvar/atualizar porque precisa comparar um por um usando seu método equals.Então você precisa de um implementação consistente é igual a ao usar uma coleção Set.
Aqui você pode ver sua contraparte no Hibernate.