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: '[email protected]'
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
[email protected]
https://lists.jboss.org/mailman/listinfo/hibernate-dev
