I have the following classe:
Depending on whether unique=true is set in getLogin's @Column, I have the following result in the generated statement :
1. getLogin with unique = true:
2. getLogin with unique = false
While the javadoc for unique explains that it is a shortcut for the UniqueConstraint annotation I would rather have Hibernate to:
1. Either fails (eg: you can't mix UniqueConstraint with unique=true)
2. Either use the name from UniqueConstraint
In the example here, Hibernate somehow determined that my UniqueConstraints correspond to something already existing (otherwise I would have two constraints, UK_6iua9a9q6jbsdakwv83vo40rm and uk_usr_login).
There are a few places where Hibernate does in fact take collected metadata and eliminates duplicates. This seems like a logical candidate because it makes no sense to apply 2 constraints here and such a case might not be supported across all dialects. It likely picks whichever was registered first so long as the columns involved match. But I'd need to look specifically at the code to verify this, but seems reasonable.
The most logical choice seems that if a @Column specifies unique=true and there is already a @UniqueConstraint defined for the same *single* column name on the @Table annotation, we skip the unique=true constraint generation and let the table's take precedence.
I would find it logical too. And because I'm curious as to what are doing other JPA implementation (Hibernate and EclipseLink), I've tested it :
The only problem with Hibernate is this issue (with a simple workaround, eg: removing unique=true).