Re: [hibernate-dev] ORM5 and naming strategies (or get me my foreign keys back!)
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.