-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
AllValidator should not check for type #26463
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Are you sure that the |
@xabbuh it matters in what order they invoked: if |
In that case I don't think that this is a bug. If you cannot ensure that the value you check using composite constraints is a collection, I suggest to add the |
@xabbuh added At the moment it's impossible to validate collections with symfony validator. I honestly cannot see what benefits that type check brings.
I surely cannot ensure (the request comes from the client and contains arbitrary data) - that's why I want to validate it, but I cannot due to a bug in the implementation. |
To clarify why it's a bug:
The |
Right, I checked other constraints and it looks like almost every other constraint check for type. Which makes symfony/validator impossible to validate an arbitrary input. That's correct: validator must be able to validate anything, but it cannot. Correct me somebody if I wrong. <?php
use Symfony\Component\Validator\Constraints\Email;
use Symfony\Component\Validator\Constraints\Type;
use Symfony\Component\Validator\Validation;
require __DIR__ . '/vendor/autoload.php';
$validator = Validation::createValidator();
$constraints = [
new Type('string'),
new Email(),
];
$violations = $validator->validate([], $constraints);
var_dump($violations); This cannot validate an email. Expected: a violation. Actual: an exception. What is the point to throw exceptions from a validator, while the validation result should be returned as a collection of violations instead? |
Thank you all for the discussion. I am going to close here in favour of #12312. |
At the moment the
AllValidator
makes the following extra check:it causes a problem to validate whether a value is an array containing only integers.
Let's see the problem in action. Let's say we have an object that has a field
$ids
that must be a non-empty array of integers. The naive attempt would be to annotate it like this:It works fine, as soon as you pass an array there. But if you pass non-array and non-iterable value, like
42
it fails miserably with the following exception:Why does the
AllValidator
throws at all?here it checks whether a value is set at all - so that you could validate it with
NotBlank
if necessary.So why does it do the type check with exception, while that part of the job should have been done a
Type("array")
constraint instead?What I suggest:
instead. In that case if the value is not an array or traversable - the validation does not run. And if one wants to ensure it's an array - they must do a naive
Type("array")
check first.The text was updated successfully, but these errors were encountered: