Allows validation by `groups` on `@Valid`

[jycr]

Like Spring Framework's @Validated annotation but in standard in Jakarta Validation Spec.

We currently cannot define validation groups on the @Validated annotation.

This should be possible, as with all other constraints annotations.

@Valid(groups = {CreationGroup.class, ModificationGroup.class})

[marko-bekhta]

Hey @jycr

Thanks for the suggestion. For this to be considered, you should present the use case for it. Note that @Valid doesn't really need the groups attribute in the sense that it is a marker to help determine whether to cascade the validation into the annotated object and then the constraints would have groups i.e. @Valid itself is not a constraint.

class MyClass {
   @Valid 
   MyOtherClass other;
}

class MyOtherClass {
   @MyConstraint(groups =...)
   String string;
}

[matevskial]

Okay here's a use case:

Imagine I have a dto for creating and updating:

public class ParentCreatePatchDto {
    
    @NotBlank
    private String field;

    @Valid(groups = Update.class)
    private ChildCreatePatchDto child;
}

public class ChildCreatePatcDto {
    @NotNull
    private String someField;
}

For creating, I want to validate the whole thing, but for patch, I don't want to validate the whole thing, I would validate the fields in ParentCreatePatchDto that don't have a group specified(that is field in this case), and then I would trigger manual validation on child after some operations done on it(example creating a new instance of the ChildCreatePatchDto that is a patched version and then just validating that patched instance to see if the patch operation did not break any constraints).

I can't understand why you choose not to interpret @Valid as a constraint: @Valid says "hey, validate this object using the rules described inside it", basically with @Valid we are describing the constraint that we want that field to be validated. If @Valid does not exist on that field, that means we don't have any validation constraints on that field.

Is there an objective reason why we can't treat @Valid as a constraint, or it's just you opinion?

[marko-bekhta]

Hey,
That's better, now that there is a description of the expectations from the groups attribute in this context.
The original request only points to the annotation from Spring -- @Validated, which has a different meaning and specifies which groups to apply when calling Validator#validate(..) rather than which groups are applicable.

The use case you've described is achievable if you push the groups to your child's dto + passing a correct set of groups to the validate(..) call:

public class ParentCreatePatchDto {
    
    @NotBlank
    private String field;

    @Valid
    private ChildCreatePatchDto child;
}

public class ChildCreatePatcDto {
    @NotNull(groups = Update.class)
    private String someField;
}

I can see how it may seem that there's a benefit of having groups on @Valid to prevent cascading into other objects, but we have to consider the implications of doing so. For example, it is expected that the object is validated for the entire group before proceeding to the next group and exploring properties marked for cascading. Following this logic, if we had groups on @Valid, it would mean that we'd need to cascade into marked properties as part of the group validation, which in turn would mean that we may end up cascading into the same property multiple times if we request validation for several groups. Doing so would be expensive and inefficient, especially if the object graph is deep.

^ and there's one of the reasons why @Valid is not a regular constraint.

A regular constraint requires that there are the following 3 attributes be defined:

validation/src/main/java/jakarta/validation/Constraint.java

Lines 25 to 34 in 75a5452

	* Each constraint annotation must host the following attributes:
	* <ul>
	* <li>{@code String message() default [...];} which should default to an error
	* message key made of the fully-qualified class name of the constraint followed by
	* {@code .message}. For example {@code "{com.acme.constraints.NotSafe.message}"}</li>
	* <li>{@code Class<?>[] groups() default {};} for user to customize the targeted
	* groups</li>
	* <li>{@code Class<? extends Payload>[] payload() default {};} for
	* extensibility purposes</li>
	* </ul>

e.g.:

validation/src/main/java/jakarta/validation/constraints/AssertFalse.java

Lines 41 to 45 in 75a5452

	String message() default "{jakarta.validation.constraints.AssertFalse.message}";
	Class<?>[] groups() default { };
	Class<? extends Payload>[] payload() default { };

and message() isn't really applicable in the context of @Valid.

If @Valid was a regular constraint, then when there is a violation in the object we cascaded into, we'd get two violations, one for the @Valid and the other for the constraint that failed in the cascaded object.

And there's more. It's not a matter of opinions, it's just that @Valid is not "your regular constraint".

That's why I'd like to see and understand a real-world, practical use case to then figure out how it can be addressed.
E.g. if we want to prevent cascading into properties, we most likely would end up adding an attribute to the @Valid but then at the same time it most likely wouldn't be called groups, so that there is a clear distinction that the behavior here is different from a regular constraint.