Hibernate GeneratedValue com Herança

8 respostas
WiLLStenico

Pessoal bom dia.

Tenho o seguinte cenário:

Uma classe Pessoa que contém Nome, Endereço,… e uma classe Cliente que tem como base a classe Pessoa.

A dúvida que tenho é, como fazer para que o campo ID seja gerado automaticamente?

Vi alguns exemplos onde o pessoal gerencia manualmente o ID, fazendo um select do max e incrementando um. Se este for o único jeito acredito que seja mais vantagem abrir mão da Herança e criar classes com campos “repetidos”.

Se alguém puder me ajudar agradeço muito.

Classe Pessoa:

@Entity
@Inheritance(strategy = InheritanceType.TABLE_PER_CLASS)
public class Pessoa {

	@Id
	@GeneratedValue(strategy = GenerationType.AUTO)
	private long id;
	
	private String nome;

	@ManyToOne
	private Endereco endereco;

        ...

       }

Classe Cliente:

@Entity
public class Cliente extends Pessoa
{

	@OneToMany
	private Set<Fatura> faturas;

	@OneToMany
	private Set<Contrato> contratos;// = new HashSet<Contrato>();

	@DateTimeFormat(pattern = "dd/MM/yyyy")
	@Temporal(TemporalType.DATE)
	private Calendar dataCadastro;


         .....

        }

Obrigado e um Feliz Natal… hahaha

8 Respostas

drsmachado

Nunca vi nada assim, ficar fazendo gambiarra para a PK.
Qual o banco de dados em questão? Qual a versão do hibernate? O que quer fazer?

WiLLStenico

Estou usando a versão 4.2 do Hibernate com banco MySQL…

Oque quero fazer é utilizar uma classe Cliente que tem como base a classe Pessoa, neste caso como fica os annotations para o campo ID ficar como auto-increment.

Segue um dos links que dizem ser impossível usar o auto-incremento dessa forma:

"This strategy does not support the IDENTITY generator strategy: the id has to be shared across several tables. Consequently, when using this strategy, you should not use AUTO nor IDENTITY. Note that in below Main class we specified the primary key explicitly."

Link: http://viralpatel.net/blogs/hibernate-inheritance-table-per-concrete-class-annotation-xml-mapping/

Detalhe, minha intenção é usar a estratégia Table_Per_Class, pois pelo que pesquisei e vi em exemplos é a maneira em que o BD não fica com campos nulos e com melhor desempenho, mas posso estar errado…

Hebert_Coelho

WiLLStenico:
Detalhe, minha intenção é usar a estratégia Table_Per_Class, pois pelo que pesquisei e vi em exemplos é a maneira em que o BD não fica com campos nulos e com melhor desempenho, mas posso estar errado…
Onde você viu falando sobre o melhor desempenho?

Se a própria api diz que não dá suporte, então não dá. Tem que ser na gambiarra ou tentar trocar de banco e usar sequence.

WiLLStenico

Era isso que eu estava procurando, alguém experiente dizendo que realmente não tem como. heheheheh

Então, temos 3 estratégias:

Single_Table: o problema é que terei campos que ficarão vazios na tabela caso eu tenha mais de uma classe com a mesma base.

Joined: Li que sua principal desvantagem é que, por ter que fazer join por trás acaba tendo um desempenho um pouco inferior.

Sendo assim sobrou a Table_Per_Class…

Me corrijam se eu estiver errado, por favor…

Geralmente vcs utilizam qual estratégia?

Obrigado novamente.

Hebert_Coelho

WiLLStenico:
Era isso que eu estava procurando, alguém experiente dizendo que realmente não tem como. heheheheh

Então, temos 3 estratégias:

Single_Table: o problema é que terei campos que ficarão vazios na tabela caso eu tenha mais de uma classe com a mesma base.

Joined: Li que sua principal desvantagem é que, por ter que fazer join por trás acaba tendo um desempenho um pouco inferior.

Sendo assim sobrou a Table_Per_Class…

Me corrijam se eu estiver errado, por favor…

Geralmente vcs utilizam qual estratégia?

Obrigado novamente.

1) Eu não disse que não funcionava, eu nunca usei table per class. É a única estratégia que não é portável entre implementações. Eu apenas afirmei em cima do que você citou
2) Novamente pergunto, onde você viu falando que a performance do table per class é melhor?
3) Eu uso single.

dudzjava

É realmente necessário nao ter campos nulos ? Eu iria de SINGLE_TABLE, mais simples, usa uma tabela só por herança e não teria que fazer gambi pra gerar id automatico.

drsmachado

Pela estrutura e pelo que o autor do tópico deseja, creio que a estratégia de herança JOINED seria a mais adequada.
Isso irá criar uma tabela por classe concreta e permitir o uso de IDENTITY como estratégia para o @GeneratedValue.

WiLLStenico

Bom pessoal, acredito que minha dúvida foi sanada.

Terei de abrir mão do Table_Per_Class mesmo. Vou experimentar o Joined e em último caso utilizo o Single_Table.

Agradeço muito a colaboração de todos principalmente por este ter sido meu primeiro tópico aqui no GUJ. Impressionante a velocidade em que recebi ajuda.

Obrigado Novamente…

Criado 26 de dezembro de 2013
Ultima resposta 26 de dez. de 2013
Respostas 8
Participantes 4