While migrating from Hibernate 3 to 5 I noticed a difference in DDL generation for columns that specify "unique=true" in native HBM-Mappings.

While Hibernate 3 uses "unique" directly in the generated CREATE TABLE statement, Hibernate 5 creates an additional ALTER TABLE statement for creating the unique constraint.

So, in the former case, the target database will create the unique constraint name, while in the latter case, Hibernate will generate the unique constraint name, something like "UK_ej7ku5lkib9euyy8cl4je00b6".

I think one way to tackle that is to use unique-key="myname" instead of using unique="true" in the HBM mapping files, but that's some effort to change all mappings.
Therefore, another idea was to customize the ImplicitNamingStrategy implementation by overriding the method "determineUniqueKeyName". But unfortunately, this method doesn't seem to be called at all. Some debugging revealed that the member "uniqueConstraintHoldersByTable" in InFlightMetadataCollectorImpl is null, so "buildUniqueKeyFromColumnNames" is never called.

As ImplicitNamingStrategy#determineUniqueKeyName has no JavaDoc, how should it be used and when should it be called?
Is it a bug that it's not called for native HBM-Mappings?
If I can't use the NamingStrategy for this, what's the recommended way to preserve the unique key constraints?

Thanks,
Holger

For Hibernate 5, you can put a breakpoint in ImplicitNamingStrategyJpaCompliantImpl#determineUniqueKeyName since that's where the unique constraints are being generated.

Anyway, what is the actual problem that you have? Are you using hbm2ddl for your system? While hbm2ddl is good for the initial schema, you might want to use FlywayDB since it's way more advanced than hbm2ddl anyway.

Unfortunately, this is not the case.
Even Hibernate 5 seems to generate the constraint name here:


Stacktrace is for version 5.0.10.
So according to your own expectations, this seems to be an oversight?

With regard to using hbm2ddl vs. FlywayDB:
When developers create a new test DB we currently use the schema generated by Hibernate.
Also for testing with in-memory DB we use this feature.
Obviously, the generated schema should be identical to the existing PROD schema.

You don't really need to use an in-memory DB during testing. You can run any RDBMS almost as fast as HSQLDB or H2 using an in-memory disk.

As for the mapping issue, you can open a Jira issue for it. Make sure that you provide a replicating test case as well. Annotations have better support than HBM in recent versions of Hibernate, so you might want to consider migrating to annotations as well. In a future version of Hibernate, HBM support might be even dropped in favor for the JPA XML mappings + some extension mechanism.

Yes, but the point here was to initialize the DB with an initial schema, be it H2 or PostgreSQL or whatever.

Ok, here is the issue about the ImplicitNamingStrategy not used consequently throughout the codebase (at least for unique key names):
https://hibernate.atlassian.net/browse/HHH-11103

Thanks for creating the Jira ticket.