- I suggest to add an explanation what the "Hibernate Metadata Impact" means. That is, before the table, add a note saying something like
Where applicable, these application-level constraints lead to creating database-level constraints described in the "Hibernate Metadata Impact" column
- For the "Apply on" column: pretty much all of these constraints can be applied either on a field or a property, so there's not much sense in repeating this in every row. I suggest to change the values in this column to only describe the Java types of properties/fields the particular constraint can be applied on. That means removing the word "property" from each row. For @AssertFalse and @AssertTrue the applicable type should be Boolean.
- I think we should distinguish those constraints which are part of the specification (so they are in the javax.validation.constraints package) from those which are specific to Hibernate Validator (these are in org.hibernate.validator.constraints. The Hibernate-Validator-specific constraints are: @Length, @NotEmpty, @Range, @Email, @CreditCardNumber, @EAN. How about we split the table into two tables, one table for the constraints from specification and one for those vendor-specific ones? The description before each table should also mention the package name where these constraints are. @Valid is an exception because even though it is from the Bean Validation specification, it is located in javax.validation package. This should probably be mentioned somewhere in its description?!
- In the example of the @Pattern constraint:
@Pattern(regex="regexp", flag=) or @Patterns( \{@Pattern(…)} )please remove the backslash before the second @Pattern annotation, it shouldn't be there. Also the correct parameter name is regexp, not regex!
- The annotations in the first column should be highlighted as code, they are currently plain text without syntax highlighting.
- clones
-
JBEAP-5097 [7.0] Dev Guide - Changes in Hibernate Validator Constraints table
-
- Closed
-