Setting a constraint via the form builder is not the same as setting a constraint on the data object. Not sure if this is a bug, but their behavior is different.

Thanks for reporting this @gmponos.

I will investigate on this, but to quickly fix your problem the workaround is to use the property path data.to when adding the constraint in the type.

@HeahDude thanks in advance. If this should behave differently then I will submit a PR to docs suggesting a notice about this and the work around you mention. For me I believe that constraints should behave the same regardless if they are defined through yaml/annotation/php/form.

This looks expected to me. When using the constraints option of the form type, the constraint will be associated with the form and thus property paths must be given according to the structure of the form as @HeahDude said. In your first example, you are attaching the constraint to your model.

I am closing as explained

Hello,

My explanation was wrong

The line above will bring back a form object.

Basically if I attach a constraint to the field I have only the field visible so if I do something like this:

        $builder
            ->add('from', ChoiceType::class, [
                'constraints' => [
                    new NotIdenticalTo(['propertyPath' => 'data.to']),
                ],
            ])

I get the following error:

PropertyAccessor requires a graph of objects or arrays to operate on, but it found type "string" while trying to traverse path "data.to" at property "to".

If I add the constraint to the form I do not have access to both parts of the comparison

    public function configureOptions(OptionsResolver $resolver): void
    {
        $resolver
            ->setDefault('constraints', function (Options $options) {
                return [
                    new NotIdenticalTo([
                        'value' => '', // what?
                        'propertyPath' => 'data.to'
                    ]),
            })
    }