Entity with TimestampableEntity trait fails on PUT operation

[mcanepa]

I'm on a fresh install of API Platform (v3.2.7) and I'm using TimestampableEntity

This is my entity (Greeting example)

<?php

namespace App\Entity;

use ApiPlatform\Metadata\ApiResource;
use Doctrine\ORM\Mapping as ORM;
use Symfony\Component\Validator\Constraints as Assert;

use Gedmo\Timestampable\Traits\TimestampableEntity;

#[ApiResource]
#[ORM\Entity]
class Greeting
{
    use TimestampableEntity;

    #[ORM\Id]
    #[ORM\Column(type: "integer")]
    #[ORM\GeneratedValue]
    private ?int $id = null;

    #[ORM\Column]
    #[Assert\NotBlank]
    public string $name = "";

    public function getId(): ?int
    {
        return $this->id;
    }
}

and my config/services.yaml

gedmo.listener.timestampable:
    class: Gedmo\Timestampable\TimestampableListener
    tags:
        - { name: doctrine.event_listener, event: 'prePersist' }
        - { name: doctrine.event_listener, event: 'onFlush' }
        - { name: doctrine.event_listener, event: 'loadClassMetadata' }

It woks fine on POST operation, but it fails when doing a PUT. I get this error

An exception occurred while executing a query: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'created_at' cannot be null

The versions I'm using are: symfony 6.4.1, doctrine 2.12, gedmo 3.14

[mcanepa]

It works with PATCH but I believe this should work with PUT as well

[greenxd]

i have the same issue, did you solve?

[RafaSRibeiro]

The same thing happens to me. Has anyone discovered the solution?

[mbabker]

There is nothing in this package behaving differently based on the HTTP request method.

The TimestampableEntity only configures an object to be timestamped when it is created. Is something happening somewhere that is causing the createdAt field to be set to null during an update?

[RafaSRibeiro]

Even adding the "Group" attribute so that it is not received by the "PUT" method, the created_at field is changed to null

[mbabker]

If your entity has a setter for that field (which if you're using the TimestampableEntity trait, it will), adding a dump(debug_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS)) to that might help figure out what's changing it. Otherwise, to me it seems like this is an API Platform issue and not a bug here.