[hibernate-dev] Naming and "naming strategies"

[Emmanuel Bernard]

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 at 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 at hibernate.org> 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 at hibernate.org>
> > wrote:
> >
> >>
> >> On 02 Feb 2015, at 17:51, Steve Ebersole <steve at hibernate.org> wrote:
> >>
> >> On Mon, Feb 2, 2015 at 8:34 AM, Emmanuel Bernard <emmanuel at hibernate.org>
> >>  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.
> >>
> >
> >
> >