Closed bobvandevijver closed 3 months ago
Thanks for the PR 😍
Define the SYMFONY_ENDPOINT
environment variable:
# On Unix-like (BSD, Linux and macOS)
export SYMFONY_ENDPOINT=https://raw.githubusercontent.com/symfony/recipes/flex/pull-1299/index.json
# On Windows
SET SYMFONY_ENDPOINT=https://raw.githubusercontent.com/symfony/recipes/flex/pull-1299/index.json
Install the package(s) related to this recipe:
composer req 'symfony/flex:^1.16'
composer req 'doctrine/doctrine-bundle:^2.12'
Don't forget to unset the SYMFONY_ENDPOINT
environment variable when done:
# On Unix-like (BSD, Linux and macOS)
unset SYMFONY_ENDPOINT
# On Windows
SET SYMFONY_ENDPOINT=
In order to help with the review stage, I'm in charge of computing the diff between the various versions of patched recipes. I'm going keep this comment up to date with any updates of the attached patch.
I do not think the action failure is something I can solve, or is it?
Hi,
Since the default value of setting doctrine.orm.controller_resolver.auto_mapping
is false
, I get the following error:
Cannot autowire argument $user of "App\Controller\ProfileController::show()": it needs an instance of "App\Entity\User" but this type has been excluded in "config/services.yaml".
My controller:
// src/Controller/ProfileController.php
namespace App\Controller;
use App\Entity\User;
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Routing\Attribute\Route;
class ProfileController
{
#[Route('/profile/{ulid}')]
public function show(Request $request, User $user): Response
{
// ...
}
}
Does changing {ulid}
to {user}
solve (or changing this config value to true)?
With {user}
, I have error:
An exception occurred while executing a query: SQLSTATE[22P02]: Invalid text representation: 7 ERROR: invalid input syntax for type integer: "1C9UESfu5Jk1kuhoF1vUh8"
CONTEXT: unnamed portal parameter $1 = '...'
With doctrine.orm.controller_resolver.auto_mapping
to true, it works but it is not recommended.
I think in your case, you'll want to explicitly use the MapEntity attribute.
It works with #[MapEntity]
// src/Controller/ProfileController.php
namespace App\Controller;
use App\Entity\User;
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Routing\Attribute\Route;
class ProfileController
{
#[Route('/profile/{ulid}')]
public function show(
Request $request,
#[MapEntity(mapping: ['ulid' => 'ulid'])] User $user
): Response {
// ...
}
}
We have the same issue as described above in the Symfony book.
We now need to use #[MapEntity(mapping: ['slug' => 'slug'])]
which seems unnecessary.
I think we should revert this change.
The auto-mapping using all fields causes lots of weird cases though (especially when you can have 2 entities in your signature. Having this feature off by default avoids lots of weird issues (which might be silent bugs)
Note that we only changed the recipes to change the value for new projects.
I'm proposing to revert this change in #1302: this breaks the DX, we need to find a better way.
FYI, I'm proposing https://github.com/symfony/symfony/pull/54455 for a possible solution to these ambiguities.
Resubmitted as https://github.com/symfony/recipes/pull/1316
Reflects the new default for doctrine.orm.controller_resolver.auto_mapping to ensure new users will not be faced with a deprecation when starting with doctrine bundle 2.12 or higher.