Embedded Write

For some reason I was missing setName in DragonTreasure
Mystery solved ))

oh heck yeah, thanks! Was having the same thing and it was stumping me.
Since I was dealing with PATCH instead of PUT because of the recent api-platform changes I was looking into that direction.

but setName() was removed when we set it in the constructor. The tutorial made it - on purpose - only settable once during creation. You get no error when you do try to change it later though.

Again, thanks, was pulling my hear out!
(Didn't even try it yet but the moment I read your comment the lightbulb went off in my head :wink:)

Hey Joris-Mak,

Thanks for mentioning that was a useful comment for you!

Cheers!

Hey @seshy,

Awesome news! Such things happens sometimes! Keep going!

Cheers!

Hey Automatix,

Hm, I don't see the User object has a description field in this video. Are you talking about a different video? Could you link me?

1) But it depends on what you update. If you update User object - that makes sense you have validation error if your User#description field has #[Assert\NotBlank()]. But if you update a different object that has relation to User - that may require #[Assert\Valid()] constant on the $user property, as it's mentioned in this video for $owner property.

2) yes, it may end up into a DB error if your field is not nullable in the DB. To make it work, you should set the field to an empty string at least and then it should not be a DB error. It depends on which behavior you want. Also, sometimes, it may depend on the DB SQL server or DB server version.

3) Mostly because PUT and PATCH operations in the ApiPlatform that is used in this video works identical, i.e. no difference. Since ApiPlatform v4 they indeed work different, so if you don't want to set all the fields that are not specified in the PUT request to NULL on the request - use PATCH or specify the field explicitly :) See the note in this section https://symfonycasts.com/screencast/api-platform/operations#put-vs-patch for more details.

I hope that helps!

Cheers!

Hey @rabbar!

I can see that you understand the mechanism of how this all works well! To summarize:

When creating a DragonTreasure, you want to allow creating a new User, but not update an existing user.

Is that accurate? If so, I think it makes sense. But in Api Platform's eyes, these are all just valid ways to change data. I'm not entirely sure how to handle this. The closest I got was to allow updating, but to add a validation check that the API client does or doesn't have permission to update this user. This is not exactly the same, but it's related and can maybe offer some inspiration: https://symfonycasts.com/screencast/api-platform-extending/simpler-validator

Let me know if you have any luck, I'd love to know!

Cheers!

"When creating a DragonTreasure, you want to allow creating a new User, but not update an existing user."
Is that accurate?

Yes.
I followed your advice with the validator. It works so far.

<?php
declare(strict_types=1);

namespace App\Validator;

use Symfony\Component\Validator\Constraint;

#[\Attribute(\Attribute::TARGET_PROPERTY | \Attribute::TARGET_METHOD)]
class DenyNestedEntityUpdateOnPost extends Constraint
{
    public string $message = 'You must not update a nested entity within a POST request.';
}

<?php
declare(strict_types=1);

namespace App\Validator;

use Doctrine\Common\Collections\ArrayCollection;
use Doctrine\Common\Collections\Collection;
use Doctrine\ORM\EntityManagerInterface;
use Symfony\Component\HttpFoundation\RequestStack;
use Symfony\Component\Validator\Constraint;
use Symfony\Component\Validator\ConstraintValidator;

class DenyNestedEntityUpdateOnPostValidator extends ConstraintValidator
{
    public function __construct(private EntityManagerInterface $entityManager, private RequestStack $requestStack)
    {
    }

    public function validate(mixed $value, Constraint $constraint): void
    {
        assert($constraint instanceof DenyNestedEntityUpdateOnPost);        

        if (null === $value || '' === $value) {
            return;
        }

        $request = $this->requestStack->getCurrentRequest();
        if (!$request || !$request->isMethod('POST')) {
            return;
        }
        
        // meant to be used above a relation field (single or collection)
        assert(is_object($value) || $value instanceof Collection);

        $unitOfWork = $this->entityManager->getUnitOfWork();
        
        $entities = $value instanceof Collection ? $value : new ArrayCollection([$value]);
        foreach ($entities as $entity) {
            
            // Check if the entity has changed
            if ($originalData = $unitOfWork->getOriginalEntityData($entity)) {
                $classMeta = $this->entityManager->getClassMetadata($entity::class);
                foreach ($classMeta->reflFields as $name => $refProp) {
                    if (!$classMeta->isCollectionValuedAssociation($name)) {
                        if ($refProp->getValue($entity) !== $originalData[$name]) {
                            $this->context->buildViolation($constraint->message)->addViolation();
                            break 2;
                        }
                    }
                }
            }
        }
    }
}

class DragonTreasure
{
    // [...]

    #[DenyNestedEntityUpdateOnPost]
    #[ORM\ManyToOne(cascade: ['persist'])]
    #[ORM\ManyToOne(inversedBy: 'dragonTreasures')]
    #[ORM\JoinColumn(nullable: false)]
    #[Groups(['treasure:read', 'treasure:write'])]
    private ?User $owner = null;
    
    // [...]
}

I have left out the checking of relation collections for now because it doesn't play a role in my case and would only make things unnecessarily complicated.

Hey @mjk!

Sorry for my very slow reply! I can see what you want to do and it makes sense. This may be related and help: https://github.com/api-platform/core/issues/5559#issuecomment-1518595331 - let me know if it does!

Cheers!

Historically API Platform would essentially treat PUT operations as PATCH operations and be used for partially updating resources. I believe in latest versions of API Platform the PUT operation now actually acts like a true PUT, where where all non-specified fields are removed (set to null) and PATCH is the method you should use if you want to partially update a resource by specifying only the fields you want to change.

tldr; when these videos use PUT you should use PATCH instead.

Hey @creativx007

As @opalint mentioned, ApiPlatform changed how they used to treat PUT operations, we have a little warning note in this chapter https://symfonycasts.com/screencast/api-platform/serializer?playAt=269#adding-a-virtual-textdescription-field

Hey @Oleguer-C!

Hmmm. I don't have any experience with Doctrine inheritance and the serializer. To debug this, I'd first try to get a stacktrace of where this error comes from. Then maybe we can work backwards from the source to see if / how you could tell the serializer that you want a CityCondition object specifically (passing the @type was a good idea... but apparently isn't enough!).

Cheers!

Thank you very much!
After managing to decorate the AbstractItemNormalizer class to use the '@type' field, I realized that it actually works by default, and the problem was that I hadn't configured the 'typeProperty' field in the 'DiscriminatorMap' annotation on the abstract class.
I'm attaching the result in case it can be useful to someone.
Cheers!

#[DiscriminatorMap(typeProperty: '@type', mapping: [
    'City' => CityCondition::class,
    'Date' => DateCondition::class,
    'DateRange' => DateRangeCondition::class,
    'MaxTemperature' => MaxTemperatureCondition::class,
    'MinTemperature' => MinTemperatureCondition::class,
    'WeekDay' => WeekDayCondition::class
])]

Fantastic! Thank you for sharing that!

Hey,

IIRC if you are persisting a new object you don't need to set back relation to it, I mean you User payload should be like

{
  "username": "userOne",
  "profile": {
       "info": "info about the user in profile",
   }
} 

That should be enough to create related objects at once.

Cheers!

Hey @Szymon!

It looks like the data on that treasure is STARTING invalid - like the coolFactor in the database is somehow already greater than 10. And so, even though you’re not changing that field, it fails validation. I think for the treasure’s name I may have a bug on the fixtures that randomly sets a name that’s longer than 50 - so that is likely the cause of that error. I might (?) have some problem also with coolFactor!

So, just a data error on the database - and probably my fault. On production, thanks to validation, that data would never be able to get into this invalid state.

Cheers!

Yeah, that is the reason, changing the getDefaults() in DragonTreasureFactory.php to something like:

`protected function getDefaults(): array

{
    return [
        'coolFactor' => self::faker()->numberBetween(1, 10),
        'description' => self::faker()->text(255),
        'isPublished' => self::faker()->boolean(),
        'name' => self::faker()->text(50),
        'plunderedAt' => \DateTimeImmutable::createFromMutable(self::faker()->dateTime()),
        'value' => self::faker()->randomNumber(),
        'owner' => UserFactory::new(),
    ];
}`

will fix it.

Regards!