In SchemaExport, the building unique constraint fragment cannot be influenced anymore.
While using an specific dialect, a unique delegate can be provided.
This unique delegate provides a method getTableCreationUniqueConstraintsFragment(Table table). In case of a unique delegate it's possible to override this method, as JavaDoc describes. During SchemaExport, the method is never called with Hibernate 5.0.2. In Version 4.3 the method was called.
Running unit test see under attachement.
Hibernate 5.0.2
I think your test here is an incorrect failure. At least in my test based on yours, the UniqueDelegate is consulted for the creation. It is not consulted for dropping. The problem really isn't even consulting the UniqueDelegate or not. The problem is that the unique keys are not dropped explicitly. However, I do not see that where we do that in 4.x either.
I like to define more precisely:
In SchemaExport creation is tested only. During creation the overridden UniqueDelegate is consulted.
Until version 4.3 overridden UniqueDelegate gets consulted for
getColumnDefinitionUniquenessFragment
getTableCreationUniqueConstraintsFragment
In version 5.0.2 overridden UniqueDelegate gets consulted for
getColumnDefinitionUniquenessFragment
getAlterTableToAddUniqueKeyCommand
getTableCreationUniqueConstraintsFragment is no longer called.
We used getTableCreationUniqueConstraintsFragment() to build a create statement like
I agree, there is a workaround by using alter table,
But the java-doc still says, its possible to override getTableCreationUniqueConstraintsFragment() ("Uniqueness can be defined in 1 of 3 ways...":
http://docs.jboss.org/hibernate/orm/5.0/javadocs/org/hibernate/dialect/unique/UniqueDelegate.html
At least a clarification in the java-doc is appreciated.
As far as dropping, I do not see anywhere in 4.x that explicitly drops the unique keys. Well, I do see it used from SchemaUpdate in 4.x, but I mean from SchemaExport I do not. So where are you seeing this call happening from?
As far as creating, that looks like a call I missed in moving to the concept of an Exporter. So the StandardTableExporter does not have a call to UniqueDelegate#getTableCreationUniqueConstraintsFragment as it problem should. So please try this as confirmation.. well one of 2 things...
Have your MyHSQLDialect (from the test) return a copy of StandardTableExporter that adds the line buf.append( dialect.getUniqueDelegate().getTableCreationUniqueConstraintsFragment( table ) ); just after the point where it adds the PK definition but before it adds table-checks (roughly line 137)
Take Hibernate source, change StandardTableExporter to do this ^^, build and use that built jar in your test
Yes, I can confirm: In case I extend my test case by adding the improved StandardTableExporter getTableCreationUniqueConstraintsFragment() gets called and the test case gets valid.
Thanks , I'll get that change into the next 5.0 bug fix release