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 <emman...@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 <st...@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 <emman...@hibernate.org>
> > wrote:
> >
> >>
> >> On 02 Feb 2015, at 17:51, Steve Ebersole <st...@hibernate.org> wrote:
> >>
> >> On Mon, Feb 2, 2015 at 8:34 AM, Emmanuel Bernard <emman...@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.
> >>
> >
> >
> >
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
