To clarify...
The same NamingStrategy is used no matter what by default. The variance
comes from the fact that each binding method calls different methods :(
Which of course makes retrofitting tough in these cases. The main use
case I have seen where this happens is in many-to-one mappings. HbmBinder
calls NamingStrategy#propertyToColumnName whereas AnnotationBinder calls
NamingStrategy#foreignKeyColumnName (well actually it calls
#propertyToColumnName first, but then calls #foreignKeyColumnName sometime
later to over-write the previous implicit name).
So, for example, a mapping like:
@ManyToOne
@JoinColumn
public Customer getCustomer();
<many-to-one name="customer" class="Customer"/>
When binding this via annotations, the foreignKeyColumnName(...) call
ultimately wins and we end up with customer_id as the column name. When
binding from hbm, the propertyToColumnName(...) call wins and we end up
with "customer" as the name. Hbm binding is wrong. This handling should
have routed through the specialized method for "join column" handling (aka,
#foreignKeyColumnName) as soon as that method was added. But that was not
done. So at the moment I think we need to keep that behavior, and simply
document that NamingStrategy#foreignKeyColumnName is only ever used in
annotation binding and that for 5.0 and ImplicitNamingStrategy that
(mis)behavior is ported in order to maintain portability.
Along the road from 5.0 to 6.0 development, one of the items was to drop
hbm.xml support (in favor of a unified orm.xml XSD), so this is a
relatively short term deal.
On a related note, currently there is a single method for handling all
forms of @JoinColumn. But there are quite a few ways in which @JoinColumn
is used, so the implementation of that often get complex. After I get this
work pushed, I'd really like people to take a look at this bit and see if
it makes sense to split those out into different methods, e.g.:
determineElementCollectionJoinColumnName(...)
determineEntityReferenceJoinColumnName(...)
...
On Mon, Feb 23, 2015 at 12:43 PM, Steve Ebersole <st...@hibernate.org>
wrote:
> See below...
>
> On Mon, Feb 23, 2015 at 3:33 AM, Emmanuel Bernard <emman...@hibernate.org>
> wrote:
>
>> 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?)
>>
>
> Actually, no. It was always org.hibernate.cfg.EJB3NamingStrategy no
> matter how you bootstrapped. EJB3NamingStartegy is, unfortunately, not
> really any of these. To be honest, I am not really sure why that one was
> ever named EJB3; it does not follow the spec in many many cases (even the
> 1.0 spec). I guess we should make ImplicitNamingStrategyLegacyJpaImpl
> conform to EJB3NamingStartegy and have that be the default.
>
>
>> 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.
>>
>
> Well you asked the question perfectly above :) "Standard" was not used at
> all to indicate compliance with the spec/standard. It was used because it
> is the standard/default impl. But still I prefer
> ImplicitNamingStrategyJpaCompliantImpl
>
>
>
>>
>> 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
