Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [bean-validation-dev] Proposed usage of @Valid by Jakarta Data specification

Hey there,

I did not spend a lot of time looking into it but scanning through the Bean Validation spec to refresh my memory, here is what comes up for me.

I think the semantic is closer to a @ValidateOnExecution annotation than @Valid which has specific cascading semantics irrespective of *when* the validation happens. I don't remember the exact reasons but we did not reuse @Valid for the usages of @ValidateOnExecution.
It might even be reusing @ValidateOnExecution for that matter (would need to add the extra TARGET)

If @Valid is used (which I think would be the wrong choice, here is a cursory list of what should be looked after to make sure it does not break things

- TraversableResolver and Node
- Concept of class parameterized providing inheritance to the usage site (e.g. T getFoo() in heriting Bar<@Valid T>
- This implied the traversal rules that are quite non trivial
- The data repo interface Would have a ValueExtractor implementation?
- ExecutableValidator like interface for these containers?
- Metadata API changes
- figure out how make Group and its annotations work the same if we go that way

So far these concepts are under chapter 11 of the bean validation spec as it describe integration standard semantics with other technologies (CDI, JPA, JSF, Jakarta EE etc)
https://jakarta.ee/specifications/bean-validation/3.0/jakarta-bean-validation-spec-3.0.html#integration


Emmanuel


On Thu, Aug 24, 2023 at 3:42 PM Nathan Rauh via bean-validation-dev <bean-validation-dev@xxxxxxxxxxx> wrote:

Hi, I'd like to check with the Jakarta Bean Validation specification group on a proposed usage of the jakarta.validation.Valid annotation for Jakarta Data.  As discussed in our issue 216, we are looking for a way to allow users to opt in to automatic validation of entities when saved via Jakarta Data repositories.  The most straightforward way for users to ask for this is to standardize the approach that existing vendors (such as Micronaut) are already using, which is that users opt in by placing the Valid annotation on the entity parameter of the repository, as follows,

 

@Repository

public interface School extends PageableRepository<@Valid Student, String> {

}

 

Because this differs somewhat from the intended purpose of the Valid annotation, I’d like to check with the Jakarta Bean Validation specification group on whether you would find this usage/overloading acceptable before defining this pattern in the Jakarta Data specification.  There are other ways we could define the ability to opt in in Jakarta Data, but this one is preferable if you find it acceptable because it matches what implementations are already doing.  Let me know what your thoughts are.

_______________________________________________
bean-validation-dev mailing list
bean-validation-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/bean-validation-dev

Back to the top