I apologize if this is a 2nd posting.

________________________________
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Muldoon
Sent: Thursday, April 24, 2008 8:04 AM
To: 'hibernate-dev@lists.jboss.org'
Subject: [hibernate-dev] Shortcomings in 
org.hibernate.id.enhanced.TableGenerator class

I'm working with the org.hibernate.id.enhanced.TableGenerator class and I've 
noticed a couple of shortcomings (imho). First and foremost, it creates one row 
in the hibernate_sequences table for each configured segment_value (as opposed 
to one row for each "target_table" as implemented within the 
MultipleHiLoPerTableGenerator). Given the fact that my id column is defined in 
an abstract BaseEntity class, I can't use the enhanced TableGenerator class as 
is (since one sequence for all of my entities is not viable for my 
application). Which leads me to my second point. All of the member variables 
are declared as private, instead of protected, which makes extending the class 
for the purpose of overriding the configure method impossible.

For what it's worth, here's the change that I had planned to make (in the 
configure method) ...

Change the setting of the segmentValue from ...

        segmentValue = params.getProperty( SEGMENT_VALUE_PARAM );
... to

        segmentValue = params.getProperty(TABLE);

Of course, such a change would change the class behavior significantly - using 
targetTable instead of segmentValue as the variable name would probably make 
sense.

So, with that said, is another class worth-while (assuming that such a change 
to the existing class would break backwards compatability)?

And, on a related note, the enhanced TableGenerator is cluster safe, right?

Thoughts?

PS. I entered a jira improvement yesterday - here's the link ...

http://opensource.atlassian.com/projects/hibernate/browse/HHH-3249
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Reply via email to