Hey!

I see that this is your first PR. That is great! Welcome!

Symfony has acontribution guide which I suggest you to read.

In short:

• Always add tests
• Keep backward compatibility (seehttps://symfony.com/bc).
• Bug fixes must be submitted against the lowest maintained branch where they apply (seehttps://symfony.com/releases)
• Features and deprecations must be submitted against the 6.4 branch.

Review the GitHub status checks of your pull request and try to solve the reported issues. If some tests are failing, try to see if they are failing because of this change.

When two Symfony core team members approve this change, it will be merged and you will become an official Symfony contributor!
If this PR is merged in a lower version branch, it will be merged up to all maintained branches within a few days.

I am going to sit back now and wait for the reviews.

Cheers!

Carsonbot

I am afraid that doing this change would be a BC break in case someone actually uses this "special" group.

From the issue, im curious about your usecase

or put different, IMHO context should tell you with groups to validate, isnt it

there can also be contradictions between groups IIUC

I had a case of a large object graph (so object to be validated had several other objects withValid constraint on them, which all also needed to be validated) and there were about 25 groups in total. So to validate the entire object every possible group on the object and every object it contained had to be specified.

It very much seems like there should be an easy way to validate an entire object regardless of group metadata; it doesn't strike me as a particularly niche case.

I am afraid that doing this change would be a BC break in case someone actually uses this "special" group.

I'm happy to change the approach if necessary (open to discussion on that), or target 7.0.

i guess it could work in some cases, till it doesnt, eg.:

#[Blank(groups: ['a'])]#[NotBlank(groups: ['b'])]public $a;

but maybe that's more of a user concern 👍

Yeah I mean you'll get a violation there, but that's expected behaviour because the constraints can't both be valid. If you had contradicting constraints, it'd be a solid indicator validating everything at once isn't your use case.

@param string|GroupSequence|array<string|GroupSequence>|null $groups

maybe supporttrue here?

Possibly. I'd be interested to get more feedback on this and other options from other maintainers before I update the PR with any new approach.

@nicolas-grekas@fabpot had this PR open for about 18 months. I still believe it's a valuable feature to provide a way to validate all constraint groups on an object. If there are concerns still about the validation group name* causing a BC-break, can we either target next major version or re-open a conversation about how else this could be solved?