Skip to content
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

Form autovalidation breaking doctrine binary type #31926

Closed
GenieTim opened this issue Jun 7, 2019 · 3 comments
Closed

Form autovalidation breaking doctrine binary type #31926

GenieTim opened this issue Jun 7, 2019 · 3 comments

Comments

@GenieTim
Copy link

GenieTim commented Jun 7, 2019

Symfony version(s) affected: 4.3.0, 4.3.1

Description

The auto-validation introduced in #27735 leads to an Assert\Length() validator to doctrine mapped fields with a length, but breaks for fields with length and type binary because of an invalid charset.

How to reproduce

  • Create an entity with a field mapping including e.g.: @ORM\Column(type = "binary", length = 4). In the following, I call this field $hash.
  • Set the value of this field to a raw one, e.g. in the constructor $this->hash = \hash('crc32', 'whateverYouWantToHash\n...\nTest', true);
  • Create a form for this entity (no need for a field for the property $hash), you can have the form entirely for another field. Submit & validate the form. It will never be valid, as the Length validator will yield the invalid charset error for our $hash field.

Possible Solution

A workaround is to either:

  • simply disable the autovalidation (for this field)
  • overwrite the validation with an Assert\Length(groups={"notexisting"})

I feel like these are workarounds because I expect the validator to not only read and interpret part, but all of the doctrine annotation.

A possible solution would be to either:

  • interpret the whole doctrine annotation
  • make Assert\Length() charset independent (I do not know if and how this would be possible)
  • validate only the submitted fields instead of the whole entity

Additional context

@xabbuh
Copy link
Member

xabbuh commented Jun 7, 2019

Are you sure this still happens with 4.3.1? I would have expected this to be fixed by #31874.

@GenieTim
Copy link
Author

GenieTim commented Jun 7, 2019

Oh. You are right, I was incautious when testing the differnt versions. Very much sorry and thanks for pointing out!

@GenieTim GenieTim closed this as completed Jun 7, 2019
@xabbuh
Copy link
Member

xabbuh commented Jun 7, 2019

@BernhardWebstudio Thank you very much for the feedback. I am glad it's solved for you. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants