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

[Guillaume Smet]

Hi Steve,

On Tue, Sep 15, 2015 at 6:49 PM, Steve Ebersole <steve at hibernate.org> wrote:

> The naming strategies are giving me a hard time: we used the
>> DefaultComponentSafeNamingStrategy before and there is no real equivalent
>> in ORM 5.
>>
>
> 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?

It wouldn't be a problem to port it but there are other problems which are
>> not directly related. For instance, the foreign keys used to be named
>> fk_<hash> and they are now named fk<a different hash>:
>>     "fk421dhylghv6secx82frew7luc" FOREIGN KEY (action_id) REFERENCES
>> auditaction(id)
>>     "fk_26d86etoechksvjt5xmjdbqqg" FOREIGN KEY (action_id) REFERENCES
>> auditaction(id)
>>
>> Same for the unique keys EXCEPT for the natural ids which are still named
>> the old way (with a uk_ prefix):
>>     "uk_idim50mwro7eanb1gn9p4xv01" UNIQUE CONSTRAINT, btree (unixname)
>> (see AnnotationBinder line 2274)
>>
>> AFAICS, there's no easy way to migrate an existing application to ORM 5 if
>> we want to let ORM update the schema. We end up with duplicated foreign
>> keys/constraints.
>>
>
> 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.


> * 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.


> * 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)

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.
"""

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.

-- 
Guillaume