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

[Steve Ebersole]

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


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.

* Shouldn't we propose naming strategies allowing a smoother transition
> from ORM 4 to 5?
>

So propose... :)



> * Should we add more prominent warnings in the migration doc?
>

Such as ...?



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