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@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
