| Re: [bean-validation-dev] Proposed usage of @Valid by Jakarta Data specification |
Emmanuel,
Thanks for your response. It is very helpful.
Reading more about ValidateOnExecution, it looks like this is how the user requests validation of repository methods per constraints that are specified on the method parameters and return value. For example, this would cause the parameters to the findStudentById method below to be validated via ExecutableValidator.validateParameters, and likewise the return value via ExecutableValidator.validateReturnValue (although the return value in my example doesn’t have any constraints),
@Repository
@ValidateOnExecution
public interface School extends DataRepository<Student, String> {
Student findByStudentId(@Min(1) @Max(99999) int studentIdNum);
Student save(Student s);
}This seems useful for method parameter constraints and return value constraints. However, what ExecutableValidator.validateParameters does not do (when I just tried it) is automatically validate constraints that are on the Student class itself, as in the case of the save method above. But if I add the @Valid annotation to the Student parameter of the save method, such that the validation cascades to it, then ExecutableValidator.validateParameters does automatically validate the constraints from the Student class,
@Repository
@ValidateOnExecution
public interface School extends DataRepository<Student, String> {
Student findByStudentId(@Min(1) @Max(99999) int studentIdNum);
Student save(@Valid Student s);
}Similarly, with ValidateOnExecution on the method,
@Repository
public interface School extends DataRepository<Student, String> {
@ValidateOnExecution
Student findByStudentId(@Min(1) @Max(99999) int studentIdNum);
@ValidateOnExecution
Student save(@Valid Student s);
}
So it looks like we need them both in combination.
Mostly, this seems fine. The problem we run into is that the user typically doesn’t provide the save method because they inherit it from a built-in convenience interface, such as PageableRepository or CrudRepository, which defines save, remove, and some other common operations for them,
@Repository
@ValidateOnExecution
public interface School extends CrudRepository<Student, String> {
Student findByStudentId(@Min(1) @Max(99999) int studentIdNum);
// common operations like save, remove, ... are inherited
}
In the above case, the user loses the place where they can put @Valid onto the save parameter. I can see why Micronaut wanted to put it on the parameterized type to the repository interface - CrudRepository<@Valid Student, String> - in an attempt to get it to cascade to methods such as save that accept the entity as a parameter. I tried invoking ExecutableValidator.validateParameters on save in this case, and it doesn’t achieve getting the validation to cascade to the constraints of the Student class that is the parameter to the save method.
I suppose one option would be to force the user to override the save operation in order to add @Valid to the parameter,
@Repository@ValidateOnExecution
public interface School extends CrudRepository<Student, String> {
Student findByStudentId(@Min(1) @Max(99999) int studentIdNum);
Student save(@Valid Student s); // duplicated by user just to add @Valid
}
The above would work, but is unfortunate because it requires duplication and extra work from the end user that defeats the purpose of why they used CrudRepository with built-in methods in the first place.
The other questions that I have are around the ValidateOnExecution annotation. Jakarta Data is looking for a pattern where automatic validation is disabled for Jakarta Data repositories unless the application specifically opts into it, which now looks like it would be done via the ValidateOnExecution annotation. We would document that mechanism in our spec. Who is responsible for interpreting the presence of ValidateOnExecution? Is it expected that the Jakarta Data provider would directly look for it (on repository classes/methods)? Or is there a way that the Jakarta Data provider should be asking Bean Validation whether a method is designed as having the ValidateOnExecution behavior? And if so, what is that mechanism? Either seems fine, but the latter would allow for Bean Validation to have other ways of designating the behavior beyond just the annotation and allow those to be taken into account.