10:11 a.m.
I've been working a bit on HHH-1904 [1] -- truncating identifiers based on a maximum
length provided by the Dialect. As an example, a quick test that has a variety of uniques
produced the constraint names in [2].
My initial strategy took metamodel's ObjectName and modified it to automatically
handle name segments and quoting. For example, `UK_FooClass_1` would be broken down into
"UK", "FooClass", and "1" segments, "_" would be
the delimiter, and quoting would be added back in whenever necessary.
I'm trying to find a decent strategy for truncating the name, either as a whole or
with each segment. The problem that I keep running into is that it's going to be
difficult to dynamically ensure that naming collisions are avoided. For example, if
embedded classes are used as entities, you could have 2 constraint names like
"UK_OuterClass$InnerClassA_1" and "UK_OuterClass$InnerClassB_1". If
the middle segment is truncated at or before the "$", it won't work.
Should we try to enforce a rule that the "unique bits" be in a specific segment
or position? Alternatively, "truncate" by hashing the name (as we do with FK
names now -- of course, no human readability)? Any other ideas?
Admittedly, I may be overthinking it. It's primarily the Hibernate-generated
constraint names that we need to worry about...
[1] https://hibernate.onjira.com/browse/HHH-1904
[2] https://gist.github.com/brmeyer/bfbc78c770904cc6fca8
Brett Meyer
Red Hat Software Engineer, Hibernate
7:44 p.m.
Not so sure a name class is going to be able to handle this in
isolation. This is really why we have the split between logical and
physical names. Internally we always unique things based on the logical
name. That part works well. In your examples, the logical names would
be something like 'UK_OuterClass$InnerClassA_1' and
'UK_OuterClass$InnerClassB_1' (though personally I think these names
ought to be based on the table names rather than class names). The
physical name is where we apply the truncation due to database imposed
size constraints. Additionally, having this controlled external to the
name class allows for better collision avoidance. Again, going back to
your example, even if 'OuterClass$InnerClassA' and
'OuterClass$InnerClassB' both resolve to the same string, if you
externalize that physical name generation you can have the
externalization handle cases where the logical names are different
(really different database objects) but where the "raw truncated" name
results in a collision by applying further uniqueness.
Of course I am also fine with hashing. If the user wants "friendly
names" they can manually name the constraints.
On 03/14/2013 10:11 AM, Brett Meyer wrote:
I've been working a bit on HHH-1904 [1] -- truncating identifiers
based on a maximum length provided by the Dialect. As an example, a quick test that has a
variety of uniques produced the constraint names in [2].
My initial strategy took metamodel's ObjectName and modified it to automatically
handle name segments and quoting. For example, `UK_FooClass_1` would be broken down into
"UK", "FooClass", and "1" segments, "_" would be
the delimiter, and quoting would be added back in whenever necessary.
I'm trying to find a decent strategy for truncating the name, either as a whole or
with each segment. The problem that I keep running into is that it's going to be
difficult to dynamically ensure that naming collisions are avoided. For example, if
embedded classes are used as entities, you could have 2 constraint names like
"UK_OuterClass$InnerClassA_1" and "UK_OuterClass$InnerClassB_1". If
the middle segment is truncated at or before the "$", it won't work.
Should we try to enforce a rule that the "unique bits" be in a specific segment
or position? Alternatively, "truncate" by hashing the name (as we do with FK
names now -- of course, no human readability)? Any other ideas?
Admittedly, I may be overthinking it. It's primarily the Hibernate-generated
constraint names that we need to worry about...
[1] https://hibernate.onjira.com/browse/HHH-1904
[2] https://gist.github.com/brmeyer/bfbc78c770904cc6fca8
Brett Meyer
Red Hat Software Engineer, Hibernate
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
4303
days inactive
4305
days old
1 comments
2 participants
participants (2)
-
Brett Meyer -
Steve Ebersole