Embedded Form Validation with @Valid

I just found out this:

This constraint cannot deal with duplicates found in a collection of items
that haven't been persisted as entities yet. You'll need to create your own
validator to handle that case.

So I guess custom validation is the way to go; Any hints/links on this one are greatly welcome :)

Hey christosp

That constraint comes shipped with Symfony since version 4.3. Give it a check: https://symfony.com/blog/ne...

Cheers!

Hey Justas!

If I understand correctly, you added 2 scientists to the Genus *before* configuring the UniqueEntity validation. And then, after adding UniqueEntity, you get this weird behavior. Is that correct? If so, I've seen this as well - I think because you're *starting* with your system in an invalid state (a state that would never be allowed if UniqueEntity were used), UniqueEntity gets confused. In the real world, you should of course always have UniqueEntity from the beginning, so you won't fall into this situation. But yea, I think there *is* some weird behavior if your system starts in this invalid state. How to fix it? Ideally, you don't need to :)... because you will use UniqueEntity to never allow this. But if you have an existing database with duplications and are now adding UniqueEntity, then you can either (A) run some sort of database migration to remove the duplicates or (B) create your own custom constraint instead of using UniqueEntity - I think UniqueEntity will always act in this way.

Cheers!

Hi Ryan,
The problem is not caused by invalid state. You can remove all the scientists, save. Then add scientist1 and scientist2, save. Then when you edit the form again (you will see scientist1 and scientist2), remove the first scientist, without saving add a new one and select scientist1 again. In the form you will see scientist2 and scientist1, then try to save. It will not let you save the form saying that scientist1 is already working on the genus. Basically if you switch the order of the scientist in the collection the unique error appears.

Hey Justas!

Ah, I see! And I can repeat the issue. Here's the problem:

Suppose you start with 2 scientists: scientist1 (e.g. GenusScientist id 5) and scientist2 (GenusScientist id 6). But, you delete scientist1 from the form and re-add him (just like you described). When you submit:

1) the UniqueEntity constraint queries the database *two* times: once to see if there is already a GenusScientist with the same user+genus as scientist1 and once to see if there is already a GenusScientist with the same user+genus as scientist2. In both cases, a result is returned: GenusScientist id 5 for "scientist1" and GenusScientist id 6 for "scientist 2"

2) the UniqueEntity constraint then checks to see if the queried GenusScientist matches exactly (===) the object that it was checking again... because if there was only 1 match found... it might be *this* GenusScientist, so it shouldn't be a duplicate. For "scientist 2", it compares GenusScientist id 6 with the one from the query, GenusScientist id 6. These are ===, so it does not create a validation constraint. BUT, for "scientist 1", it compares two GenusScientist objects that are *almost* (but not quite) identical. They have all the same fields... except for "id": the one from the database of course has id 6, but the one that was just submitted has a *null* id - because this was just created by our form system. Hence, a validation error is added.

So, that's the problem :/. This issue might be related: https://github.com/symfony/.... How can we fix it? Ideally, we'd like our form to NOT create a *new* GenusScientist when one is simply removed and then re-added. The only way I can think to do this, however, would be to add some extra JS code that when the user creates a *new* scientist and assigns a user that was previously in the form, you actually dynamically update its "name" index to match the original one. In the above example, "scientist1" would originally have index 0. When you re-add it, it would have index 2. You would need to detect when the user drop-down is changed to "scientist1" and dynamically reset the index to 0. Then, when you submit, it will not look like a *new* entity anymore. Of course, that's a pretty ugly solution :). The only other alternative I can think of is to not use the UniqueEntity validator and write your own - something that looked at the "genusScientists" property directly, and checked the entire array to see if there were duplicates, before saving.

I'm not sure there's a bug in the UniqueEntity validator... but certainly because of the way it's all setup, it just doesn't have enough knowledge to get things "perfect" for our situation.

Let me know if that helps! Cheers!

And actually, a good way to do that custom constraint might just be to do a Callback constraint on the Genus entity - you could easily loop through genusScientists to see if there are any duplicates. If that works (seems like it should), that would be a super simple solution!

Hey TamNC!

Are you talking about the UniqueEntity error ? if that the case, remember to set up the "errorPath" option to the user field, so it will appear inside the user input field.

Have a nice day!

Hey Louis,

You have a good tip in this error message: you just have to use the "Symfony\Component\Form\FormEvent" namespace in the GenusFormType class. ;)

Cheers!

Hey Marcus

In that case you will have to define your constraints directly in every parent FormType, so can customize them as you need, something like this:

// some FormType.php

public function buildForm(FormBuilderInterface $builder, array $options)
{
    $builder->add('someField', EmbeddedFormType::class, [
        'constraints' => [
            new NotBlank(),
            // more constraints specific to this FormType
        ]
    ]
}

if you need to do more logic, you may want to take a look at Form Events: https://symfony.com/doc/current/form/events.html

Cheers!