[hibernate-dev] Shortcomings in org.hibernate.id.enhanced.TableGenerator class

[Steve Ebersole]

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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


-----------------------------
Steve Ebersole

Project Lead
http://hibernate.org
steve at hibernate.org




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hibernate-dev/attachments/20080516/8f336bf5/attachment.html