Hey!

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

Symfony has a contribution guide which I suggest you to read.

In short:

• Always add tests
• Keep backward compatibility (see https://symfony.com/bc).
• Bug fixes must be submitted against the lowest maintained branch where they apply (see https://symfony.com/releases)
• Features and deprecations must be submitted against the 7.1 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

Hey!

Thanks for your PR. You are targeting branch "6.4" but it seems your PR description refers to branch "6.4,".
Could you update the PR description or change target branch? This helps core maintainers a lot.

Cheers!

Carsonbot

I rebased the PR for 5.4 where the issue exists. It's strange that we didn't notice the deprecation before. It likely means that this code path is not tested. Could you please have a look and add a test case if none covers this line?

Problem with V5.4 is compatible with Doctrine/Orm < 2.10.3 where change was made,

For 5.4, it would be necessary to test if the return is an array or an object, per example :

    $length = is_array($mapping) ? $mapping['length'] : $mapping->length;

    if (isset($length)) {
        return new ValueGuess($length, Guess::HIGH_CONFIDENCE);
    }

For information, I have this deprecation after update Orm to V3.1 directly when a form based on an entity was handled :

        $form = $this->createForm(TestType::class, new Test());

        $form->handleRequest($request);

I will try to add a test.

Thanks. Yes, we'd need this "is_array" test indeed on 5.4.
Note that we don't merge PRs with merge commits in them so you'd need to squash or revert --hard to the previous commit (I'm not sure the merge commit is needed).
Note for your next PR: it's better to create dedicated feature branches instead of committing to your "6.4" directly ;)
Let me know if you need help.
Thanks for the tests!

I saw that, sorry :)
for 5.4 you made the changes?

I didn't, please add them and I'll take care of the rebase/retarget for 5.4 before merging.

made it in #54271

Closing in favor of #54271 then.