Problema com GeneratedValue x Oracle [Resolvido]

Assuntos Gerais
#1

Pessoal, percebi que está ocorrendo algo estranho ao inserir dados usando hibernate. O método inserir incrementa a sequence corretamente, porém, o campo ID grava com outro valor, por exemplo, se o NEXT NUMBER da sequence é 4, qdo insiro o registro, ao invés de gravar 4, ele grava 200, percebi que ele grava SEQUENCE * 50, pq tá indo de 50 em 50!!! Pq ocorre isso ?

veja meu código abaixo, como incremento a sequence com hibernate:

@Entity
@Table(name="wf_ausencia")
@SequenceGenerator(
	     name="sequence",
	     sequenceName="wf_sq_ausencia"
	 )
public class Ausencia {
	
@Id
@GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "sequence")
private Long 	id_ausencia;

...
..
...

Valew.

#2

Provavelmente sua sequence está marcada para utilizar cache.

Veja como retirar o cache da sequence.

#3

[quote=nbluis]Provavelmente sua sequence está marcada para utilizar cache.

Veja como retirar o cache da sequence.
[/quote]

Eu crio as sequences já para não utilizar cache:

create sequence SQ_AUSENCIA
minvalue 1
maxvalue 999999999999999999999999999
start with 4
increment by 1
nocache;

O estranho é que ele incrementa a sequence certinho, como já disse, enquanto ele grava 200 no campo ID do registro, o NEXT NUMBER da sequence vai para 5 e não 201 ou 250.

Valew.

#4

Acho que esse link resolve o seu problema:

http://www.portaljava.com/home/modules.php?name=Forums&file=viewtopic&p=148188

#5

[quote=lfpolli]Acho que esse link resolve o seu problema:

http://www.portaljava.com/home/modules.php?name=Forums&file=viewtopic&p=148188[/quote]

Sim, resolveu, foi só setar o allocationSize =1 na anotação @SequenceGenerator.

Obrigado.

Veja como ficou meu código:

@Entity
@Table(name="wf_ausencia")
@SequenceGenerator(
	     name="sequence_ausencia",
	     sequenceName="wf_sq_ausencia",
	     allocationSize=1
	 )
public class Ausencia {
	
@Id
@GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "sequence_ausencia")
private Long 	id_ausencia;
.
.
.
#6