I was really only considering XML metadata when writing that generator
and thus did not even consider the scenario of defining the identifier
annotations on a superclass.
I do not like this proposal as it completely whacks one of the
intended benefits of allowing sharing of segments between entities.
What I'd propose instead is exactly how MultipleHiLoPerTableGenerator
handles it:
String keyValue = PropertiesHelper.getString(PK_VALUE_NAME, params,
params.getProperty(TABLE) );
which would look like this for the enhanced TableGenerator:
segmentValue = PropertiesHelper.getString( SEGMENT_VALUE_PARAM,
params, params.getProperty(TABLE) );
So, if the SEGMENT_VALUE_PARAM ( "segment_value" ) is not specified,
we default to using the target table name as the segment. This does
break existing usages relying on the corny (though explicitly warned
against) default value of 'default'.
On Apr 24, 2008, at 7:03 AM, Tom Muldoon wrote:
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
-----------------------------
Steve Ebersole
Project Lead
http://hibernate.org
steve(a)hibernate.org