[hibernate-dev] ORM5 and naming strategies (or get me my foreign keys back!)

[Steve Ebersole]

>
> org.hibernate.boot.model.naming.ImplicitNamingStrategyComponentPathImpl is
>> the corolary.  These may or may not migrate directly due to the *split*.
>> The old NamingStrategy actually covered implicit naming, physical naming
>> and logical naming; whereas we have now split these out into distinct
>> contracts (well for implicit and physical anyway; it was never a good idea
>> to expose logical naming as a pluggable contract).
>>
>
> Not exactly. It inherits from JpaCompliant strategy whereas DefaultComponentSafeNamingStrategy
> inherits from EJB3NamingStrategy.
>
> So if you used DefaultComponentSafeNamingStrategy, you need to have
> something like ImplicitNamingStrategyComponentPathImpl but inheriting
> from LegacyJpa.
>
> That's what I did. Maybe we should include it to provide an easier upgrade
> path?
>

Well as I said these are not direct.  And no, I do not want propagation of
out-of-the-box strategies to cover all the legacy NamingStrategy impls.  We
have a few we care about, and I'd rather focus on those and on making the
contracts usable enough for folks to write a useful custom one as needed.


>>> Well the bottom line is that schema tooling was never a supported
>> feature prior to 5.0.  We "supported" schema creation and dropping as so
>> far as it was needed for supporting the JPA feature.  But migration and
>> validation never considered supported prior to 5.0
>>
>> I know people liked to use these features as if they were supported, but
>> they weren't.
>>
>
> Yes I know but I think we should provide more guidance and put prominent
> warnings for people using it.
>

Again, like what?  Its great to say "more guidance and better warnings",
but at some point that has to correlate to some concrete action.  So what
exactly are you proposing?


>
>
>> * Shouldn't we propose naming strategies allowing a smoother transition
>>> from ORM 4 to 5?
>>>
>>
>> So propose... :)
>>
>
> I thought about it and I think it's better to break things in a major
> version upgrade rather than having one more legacy naming strategy. We
> already have too many of them.
>

+1


>
>
>> * Should we add more prominent warnings in the migration doc?
>>>
>>
>> Such as ...?
>>
>
> I was thinking of something like:
> """
> The following table provide guidance on how to migrate your existing
> configuration:
>
> Old naming strategy || Physical naming strategy || Logical naming strategy
> (with sensible values)
>

But see this is exactly the problem.  The old naming strategy contract
mixed implicit naming, physical naming and logical naming.  And even worse
the impls applied them all inconsistently.  Not to mention that 4.2/4.3
added a whole new level of complexity on top of these.  So there really is
no simple mapping like you propose.

Now if you want to write a block in the migration guide about each of the
out-of-the-box legacy NamingStrategy impls and how to best migrate that to
5.0 I think that would be hugely valuable.




> Note that if you set the hbmddl setting to update (which was never
> officially supported until ORM 5.x), you need to be extra careful in your
> migration because the names of database objects (foreign keys, unique keys)
> generated by ORM 5.x might be different from the names generated by ORM
> 4.x. You might need to clean up your existing databases from the duplicated
> objects.
> """
>

+1


> WDYT?
>
> * Should the prefix naming be consistent (e.g. with or without an
>>> underscore)? I personally like it better with the underscore.
>>>
>>
>>
>> Really it is a practical point.  Some databases limit object name
>> length.  An underscore takes up one (arguably unnecessary) character
>> position.  I guess it is conceivable that we add the underscore in the
>> ImplicitNamingStrategy and then conditionally remove it in the
>> PhysicalNamingStrategy.
>>
>
> After thinking about it, it's better if we break the conventions for the
> constraint names: it's easier to find the old ones to drop them!
>
> But, I think we should be consistent between foreign keys and unique keys.
> Currently, the prefix for foreign keys if "FK" and the prefix for unique
> keys "UK_" with an underscore.
>

In general I think being consistent is good.