Chave composta com hibernate

26 respostas
A

Boa tarde a todos, estou precisando de uma ajudinha para começar a estudar o hibernate.
Bom, seguinte tenho as seguintes classes :

Classe : Grupo
Atributos : ( idGrupo, descricaoGrupo )

Classe : Produto
Atributos : ( idGrupo, idProduto, descricaoProduto ) .

gotaria de saber como mapear a classe produto com o hibernate. Como ficaria a definição das chaves primarias ?

Sei que a classe Grupo eu identifico o campo chave dessa forma :

@Id

@Column(name=id_grupo)

private Integer idGrupo;

Mas não sei como fazer com a classe Produto.

Desde ja agradeço pela atenção.

26 Respostas

thiagocg

Olá acmedis, já que vc esta começando a estudar hibernate, no link abaixo vc vai encontrar muitos artigos interessantes sobre hibernate.

http://www.j2eebrasil.com.br/tags/hibernate

[]'s

L

http://docs.jboss.org/hibernate/stable/annotations/reference/en/html_single/#d0e1700

A

valeu, pessoal.

Lavieri

Não use Chave Composta!!!

exceto sobre ameaça de morte hehehe… claro essa é a apenas uma opinião minha

prefica uma chave única =P

thiagocg

Não use Chave Composta!!!

exceto sobre ameaça de morte hehehe… claro essa é a apenas uma opinião minha

Lavieri, concordo em genero, numero e grau com esta sua afirmação!

[]'s

L

Lavieri, pq não?

Ex:
vc tem Casa(rua,numero), sendo que a cada rua inicia-se uma nova sequencia de numeros…

vc cria um novo atributo indentificador???
tipo Casa(id,rua,numero)

L

e ainda cria um novo indice pra garantir a unicidade (rua,numero)

thiagocg

Olá lauronolasco, concordo que em alguns casos (exigencia do cliente, analista, bd legado, ameaça de morte…) devemos utilizar a chave composta, mas na maioria dos casos o uso de uma simples chave única resolve muito bem o problema.

Eu sou a favor da regra “mantenha simples”.

Forte abraço!

Lavieri

ai vc imagina que o cara digitou, a rua ou o número errado… e como vc faz ?? vai lá e troca ? uma coisa que é o ID do registro ?

como proceder ?

e mais… vc precisa referenciar essa Casa, vai ter q referenciar 2 campos ?? já imaginou o inconveninete ?

ai vc começa a compor essa casa de chave dupla, com outras tabelas, e vai acabar cheio de campos

vai fazer um Relacionamento N-N … vai ficar cheio de campos ?

tem centenas de incovenientes

sem falar que… o ideal para chaves de banco (na minha opinião como sempre) são números, e isso pode dificultar o processo, enfim, existe milhoes de problemas

Ahh sem falar que no hibernate é impossivel trocar uma chave, não por ele, vai ter q fazer cambiarra pra trocar uma propriedade que é parte do ID

Lavieri

outra coisa

Um identificador RUA/NUMERO é mais lento que um identificador ID, único…

a RUA/NUMERO não precisa ser o indice, pode ser apenas um UNIQUE CONSTRAINT composto.

Voltando ao assunto… ai vc Tem

Fulano (nome,cpf,etcs) tem uma casa

ai Fulano tem 1 casa (ruaX,numeroTal)

ai alguem foi e alugou a casa do Fulano portanto Alugou(ruaX,numeroTal,OutroFulano)

ai o tal do fulano viu que digitou o numero errado, e precis aalterar, porem o OutroFulano que alugou a casa, alugou realmente a casa do FULANO, como fazer ? como alterar os IDs em todos os lugares ??

imagina isso em cadeias abusrdas dentro de um mega banco cheio de registros… imagina ?

e por ai vai… eu não usuario composição de chaves… eu uso e mapeio em bancos legados, mas nunca crio um por conta propria, ou seja, uso sobre ameaça de morte…

L

com o hibernate é possível vc alterar a chave primária… desde que vc carregue o objeto com a antiga chave antes de atualizar.

L

UNIQUE não é um índice??

walacy

Odeio chave composta…

Acho bem melhor criar um indice para a chave e mandar uma restrição de “unicidade” para o que seria a chave composta…

Ajuda o hibernate na hora de fazer os cascades, etc e talz…

L

Não costumo utilizar tanto, mas também não tenho todo esse repúdio.
rsrsrs

walacy

Só um exemplo que me faz não usar…

Tinhamos uma tabela com chave composta de 3 colunas… Era referenciada por uma outra tabela (1…N).

Um belo dia foi necessário incluir mais um campo na chave…

Deu impacto na outra tabela… os registros que já existiam tiveram que ser apagados…

Na aplicação, haviam algumas referencias à chave, então tivemos que sair buscando as referências e testando tudo…

Ou seja, se fosse uma chave sequencial, só teria que alterar a restrição “unique”.

Entendeu? hehehe

Abraços!

Lavieri

com o hibernate é possível vc alterar a chave primária… desde que vc carregue o objeto com a antiga chave antes de atualizar.

tenta fazer isso que vc falou =x

ele salva uma nova entidade e nao altera nao

walacy

com o hibernate é possível vc alterar a chave primária… desde que vc carregue o objeto com a antiga chave antes de atualizar.

tenta fazer isso que vc falou =x

ele salva uma nova entidade e nao altera nao

Só altera na mão, montando a query…

Lavieri

UNIQUE não é um índice??

nop nao e’ …

e tipo, como proceder com alteracoes em valores que sao os proprios indices ?

walacy

não procede…

o hibernate/jpa não altera os valores da chave…

quando precisei fazer isso, fiz um query hql e talz…

Lavieri

walacy:
não procede…

o hibernate/jpa não altera os valores da chave…

quando precisei fazer isso, fiz um query hql e talz…

nem por hql adianta… pois vc tera que refletir por todos os relacionamentos a alteracao… e’ simplismente inviavel

walacy

verdade…

cara, não tinha pensado nisso…

ainda bem que eu mudei de empresa… hahahahahahahahahaha

L

perdão… foi o vício no EMS SQL Manager…

As uniques ficam na aba “Índices”

L

Se vc defineo relacionamento como UPDATE CASCADE no próprio banco, ele mesmo cuida do cascateamento.

L

Perdão novamente…

Eu realmente nunca tinha testado a atualização de chave primária no hb/jpa…
e hj constatei que realmente não funciona… rsrsrs

O mais interessate é que a exceção lançada identifica que a chave foi modificada e inclusive qual era o antigo valor da mesma…
O que não entendo é: se já se conhece o antigo valor da chave, qual a dificuldade de implementar a atualização da pk???

Lavieri

lauronolasco:
Perdão novamente…

Eu realmente nunca tinha testado a atualização de chave primária no hb/jpa…
e hj constatei que realmente não funciona… rsrsrs

O mais interessate é que a exceção lançada identifica que a chave foi modificada e inclusive qual era o antigo valor da mesma…
O que não entendo é: se já se conhece o antigo valor da chave, qual a dificuldade de implementar a atualização da pk???

a de que uma Identificador não pode mudar

L

Se não pode, pq o sgbd permite que seja mudada?

Criado 16 de março de 2010
Ultima resposta 18 de mar. de 2010
Respostas 26
Participantes 5