<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>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. </div><div><br></div><div>I do not like this proposal as it completely whacks one of the intended benefits of allowing sharing of segments between entities.</div><div><br></div><div>What I'd propose instead is exactly how MultipleHiLoPerTableGenerator handles it:</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>String keyValue = PropertiesHelper.getString(PK_VALUE_NAME, params, params.getProperty(TABLE) ); </div><div><br></div><div>which would look like this for the enhanced TableGenerator:</div><div><div><span class="Apple-tab-span" style="white-space:pre"> </span>segmentValue = PropertiesHelper.getString( SEGMENT_VALUE_PARAM, params, params.getProperty(TABLE) ); </div><div><br></div><div>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'.</div></div><div><br></div><div>On Apr 24, 2008, at 7:03 AM, Tom Muldoon wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"> <div> <div dir="ltr" align="left"><font face="Arial" size="2"><span class="655351611-24042008">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). </span></font><font face="Arial" size="2"><span class="655351611-24042008">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. </span></font></div> <div><font face="Arial" size="2"><span class="655351611-24042008"></span></font> </div> <div><font face="Arial" size="2"><span class="655351611-24042008">For what it's worth, here's the change that I had planned to make (in the configure method) ...</span></font></div> <div><font face="Arial" size="2"><span class="655351611-24042008"></span></font> </div> <div><font face="Arial" size="2"><span class="655351611-24042008">Change the setting of the segmentValue from ...</span></font></div> <div><font face="Arial" size="2"><span class="655351611-24042008"></span></font> </div> <div><font face="Arial" size="2"> segmentValue = params.getProperty( SEGMENT_VALUE_PARAM );<br></font></div> <div><font size="+0"><span class="655351611-24042008"><font face="Arial" size="2">... to</font></span></font></div> <div><font size="+0"><span class="655351611-24042008"><font face="Arial" size="2"></font></span></font> </div> <div><font size="+0"><span class="655351611-24042008"><font face="Arial" size="2"> segmentValue = params.getProperty(TABLE);</font></span></font></div> <div><font face="Arial" size="2"></font> </div> <div><span class="655351611-24042008"><font face="Arial" size="2">Of course, such a change would change the class behavior significantly - using targetTable instead of segmentValue as the variable name would probably make sense. </font></span></div> <div><span class="655351611-24042008"><font face="Arial" size="2"></font></span> </div> <div><span class="655351611-24042008"><font face="Arial" size="2">So, with that said, is another class worth-while (assuming that such a change to the existing class would break backwards compatability)? </font></span></div> <div><span class="655351611-24042008"><font face="Arial" size="2"></font></span> </div> <div><span class="655351611-24042008"><font face="Arial"><font size="2">And, on a related note, the enhanced TableGenerator is cluster safe, right?<span class="063450112-24042008"><font color="#0000ff"> </font></span></font></font></span></div> <div><span class="655351611-24042008"><font face="Arial"><font size="2"><span class="063450112-24042008"></span></font></font></span> </div> <div><span class="655351611-24042008"><font face="Arial"><font size="2"><span class="063450112-24042008">Thoughts? </span></font></font></span></div> <div><span class="655351611-24042008"><font face="Arial" size="2"></font></span> </div> <div><span class="655351611-24042008"><font face="Arial" size="2">PS. I entered a jira improvement yesterday - here's the link ...</font></span></div> <div><span class="655351611-24042008"><font face="Arial" size="2"></font></span> </div> <div><span class="655351611-24042008"><font face="Arial" size="2"><a href="http://opensource.atlassian.com/projects/hibernate/browse/HHH-3249">http://opensource.atlassian.com/projects/hibernate/browse/HHH-3249</a></font></span></div></div> _______________________________________________<br>hibernate-dev mailing list<br><a href="mailto:hibernate-dev@lists.jboss.org">hibernate-dev@lists.jboss.org</a><br>https://lists.jboss.org/mailman/listinfo/hibernate-dev<br></blockquote></div><br><div apple-content-edited="true"> <span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div><br class="Apple-interchange-newline">-----------------------------</div><div>Steve Ebersole</div><div><br class="webkit-block-placeholder"></div><div>Project Lead</div><div><a href="http://hibernate.org">http://hibernate.org</a></div><div><a href="mailto:steve@hibernate.org">steve@hibernate.org</a></div><div><br class="webkit-block-placeholder"></div></div></div></span><br class="Apple-interchange-newline"></span><br class="Apple-interchange-newline"></div></span> </div><br></body></html>