-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 4 posts ] 
Author Message
 Post subject: JPA/Hibernate's pk generator strategy with PGSQL issues
PostPosted: Thu Jun 07, 2007 6:45 pm 
Newbie

Joined: Thu Jun 07, 2007 6:37 pm
Posts: 3
I posted this in the JBoss forum's but came upon this more active Forum with respect to JUST hibernate. So here goes:

The default strategy is AUTO which according to the HibernateExt annotation processor dwindles into a "native" which eventually leads the EntityPersister handling these entities (such as the SingleTablePersister) to use the SequenceGenerator because the PostgresDialect's getNativeIdentiterGenerator returns this class (cool). Fine, but when the SequenceGenerator is configured, it creates a sequence called "hibernate_sequence" which is used to basically generate values (1,2,3 so on) for all tables....that does not seem kosher by any means....is this true?

It seems to me that if I have all my entities as AUTO then Hibernate should use create a per table, table_column_seq variable (SEQUENCE) to manage primary keys.

I've debugged this now over two days since Hibernate is new to me. Can someone who is knowledgeable with the source (and not dangerous like myself) comment on my observation? Is this really true?

I understand that a lot of folks are using @SequenceGenerator to solve some of this but I would much rather stay database agnostic and let my Persistence provider handle the details. For example, MySQL would not use sequences and instead use identity columns. Also, the problem with switching to using the @SequenceGenerator is I have existing tables and creating a sequence would flip it back to 1 which is no good.

I would really really appreciate any comments on the above issue.


Top
 Profile  
 
 Post subject: Re: JPA/Hibernate's pk generator strategy with PGSQL issues
PostPosted: Thu Jun 07, 2007 6:49 pm 
Newbie

Joined: Thu Jun 07, 2007 6:37 pm
Posts: 3
pisymbol wrote:
I posted this in the JBoss forum's but came upon this more active Forum with respect to JUST hibernate.


And as such I forgot to mention the problem (dah):

The problem is that we have come across situations where Hibernate reuses a primary key that has been previous deleted (Entity was removed) which recycles the key generator causing exceptions.

So we have one Entity table that had 1,2,3 etc. till 43 and then 4 was deleted. Then we saw that a new Entity caused 4 to be reused so the next Entity is now 5 causing an EntityExists exception and the transaction fails. That's pretty much the pattern we see (this with the Hibernate shipped in JBoss404GA which I believe 3rc2 something or other - it flies by during deployment).

I decided to debug Hibernate itself and figure out exactly how it was determining what the next key is...etc...and stumbled across the above which I believe is the root of my problem.

Thanks again!


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jun 08, 2007 2:50 pm 
Newbie

Joined: Thu Jun 07, 2007 6:37 pm
Posts: 3
No one has seen this before? Does anyone use AUTO for postgres?


Top
 Profile  
 
 Post subject:
PostPosted: Fri Aug 17, 2007 12:12 am 
Regular
Regular

Joined: Wed Aug 25, 2004 7:40 pm
Posts: 65
I use "native" for entity ID in PostgreSQL. It works for me. I don't think you shall use "auto" for your entity ID sequence.


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 4 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.