Re: [hibernate-dev] Naming and "naming strategies"

Which one do you intend being the default? In 4.x AFAIR, it was * ImplicitNamingStrategyLegacyHbmImpl's behavior if you started ORM with the classic APIs. * ImplicitNamingStrategyLegacyJpaImpl's behavior if you started ORM via the JPA APIS (or was it ImplicitNamingStrategyStandardImpl?)

About names, I'm tempted to have: * ImplicitNamingStrategyJpaCompliantImpl * ImplicitNamingStrategyLegacyJpaImpl * ImplicitNamingStrategyLegacyHbmImpl * ImplicitNamingStrategyComponentPathImpl

The idea is to make the names explicit with the intent. "Standard" does not mean much per se.

Emmanuel On Fri 2015-02-20 12:57, Steve Ebersole wrote: > So at the moment I have the following ImplicitNamingStrategy impls: > > 1) ImplicitNamingStrategyStandardImpl - Which is compliant with the rules > set forth in the JPA standard > 2) ImplicitNamingStrategyLegacyJpaImpl - Which implements the initial > support done for JPA 1, before JPA 2 clarified some things. > 3) ImplicitNamingStrategyLegacyHbmImpl - Support dating back to the dawn of > time... > 4) ImplicitNamingStrategyComponentSafeImpl - Mainly a port > of DefaultComponentSafeNamingStrategy, although leveraging the > AttributePath stuff I discussed earlier > > Couple of thoughts... > > First, we might want to rename ImplicitNamingStrategyLegacyJpaImpl to > ImplicitNamingStrategyStandardImpl, and ImplicitNamingStrategyStandardImpl > to ImplicitNamingStrategyJpaCompliantImpl. WDYT? > > Second, I do not really like the phrase "component safe". "Safe" from > what? The difference is that the whole component path is used in > determining the name; so how about ImplicitNamingStrategyComponentPathImpl? > > I do not plan on porting any of the other NamingStrategy impls. > > > Also, here is the complete list of implicit naming hooks: > 1) primary table > 2) join table > 3) collection table > 4) discriminator column > 5) tenant id column > 6) id column (entity and idbag) > 7) basic column > 8) join column > 9) pk join column > 10 ) @Any discriminator column > 11) @Any key column > 12) map key column > 13) list index column > 14) foreign key name > 15) unique key name > 16) index name > > > On Mon, Feb 2, 2015 at 3:13 PM, Emmanuel Bernard <emmanuel(a)hibernate.org > > wrote: > > > I’d say +1 for adding coverage of them in the implicit naming strategy. > > > > On 02 Feb 2015, at 19:16, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > > > > They do not. HBM, e.g., uses "idx" for map keys columns as well as > > list/array index columns. JPA says to use {attribute-name}_ORDER for list > > index column. Unless I missed it (which is completely possible in > > annotation binding) we always use the JPA-defined default in those cases > > rather than using any *implicit* naming hooks. > > > > So that is really the question. Do we want expand the breadth of what is > > covered by implicit naming strategy in this new model? I think its > > reasonable. > > > > On Mon, Feb 2, 2015 at 11:28 AM, Emmanuel Bernard < emmanuel(a)hibernate.org&gt; > > wrote: > > > >> > >> On 02 Feb 2015, at 17:51, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > >> > >> On Mon, Feb 2, 2015 at 8:34 AM, Emmanuel Bernard < emmanuel(a)hibernate.org&gt; > >> wrote: > >> > >> I think you’re missing things like @MapKeyColumn, @OrderColumn > >>> > >> > >> So that's a good discussion. These are things that have previously been > >> hard-coded defaults (at least on hbm side) and therefore had no specific > >> naming strategy hooks. I'm all for being specific, so if everyone agrees > >> it is a good idea to add methods for stuff like this, I am fine with that. > >> > >> > >> I know JPA has well defined values for these. I am not sure they match > >> 100% the HBM version. > >> > > > > > >