4:10 p.m.
Hi all,
(starting with kudos to Steve for the 5 release, it's the first problem I
find in my migration journey)
I'm currently working on porting 2 of our existing applications to ORM 5 (I
already ported our template application to start new projects).
The naming strategies are giving me a hard time: we used the
DefaultComponentSafeNamingStrategy before and there is no real equivalent
in ORM 5.
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.
So a few questions:
* Am I the only one who sees this as a problem?
* Shouldn't we propose naming strategies allowing a smoother transition
from ORM 4 to 5?
* Should we add more prominent warnings in the migration doc?
* Should the prefix naming be consistent (e.g. with or without an
underscore)? I personally like it better with the underscore.
--
Guillaume
6:49 p.m.
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.
8:55 p.m.
Hi Steve,
On Tue, Sep 15, 2015 at 6:49 PM, Steve Ebersole <steve(a)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
7:06 p.m.
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.
3138
days inactive
3139
days old
3 comments
2 participants
participants (2)
-
Guillaume Smet -
Steve Ebersole