The bundle not set automatcly the value to updated_at and created_at columns when persisting data

[hyper112]

I got this error : Gedmo\Timestampable\Mapping\Event\Adapter\ORM::getRawDateValue(): Argument #1 ($mapping) must be of type array, Doctrine\ORM\Mapping\FieldMapping given, called in /home/{user}/projects/symfony6-test/v
endor/gedmo/doctrine-extensions/src/Timestampable/Mapping/Event/Adapter/ORM.php on line 35
knowing that the configuration is ok inside the file stof_doctrine_extensions.yaml : stof_doctrine_extensions:
default_locale: en_US
orm:
default:
timestampable: true

[mbabker]

This package does not yet support ORM 3.0 as noted by #2708, which given the error message you've provided, is what you have installed. Update to the latest release of this package, and downgrade the ORM to 2.18.

[subiabre]

This package does not yet support ORM 3.0 as noted by #2708, which given the error message you've provided, is what you have installed. Update to the latest release of this package, and downgrade the ORM to 2.18.

Is there any open PR or active development plans to support ORM 3.0?

[medamine980]

I got this error : Gedmo\Timestampable\Mapping\Event\Adapter\ORM::getRawDateValue(): Argument #1 ($mapping) must be of type array, Doctrine\ORM\Mapping\FieldMapping given, called in /home/{user}/projects/symfony6-test/v endor/gedmo/doctrine-extensions/src/Timestampable/Mapping/Event/Adapter/ORM.php on line 35 knowing that the configuration is ok inside the file stof_doctrine_extensions.yaml : stof_doctrine_extensions: default_locale: en_US orm: default: timestampable: true

I came across this issue too; for now what I've done to deal with the issue is going to the specified file vendor/gedmo/doctrine-extensions/src/Timestampable/Mapping/Event/Adapter/ORM.php, then to the method private function getRawDateValue(array $mapping) and changed the type hinting the the parameter $mapping to \Doctrine\ORM\Mapping\FieldMapping, so the final result: private function getRawDateValue(\Doctrine\ORM\Mapping\FieldMapping $mapping)

[subiabre]

This package does not yet support ORM 3.0 as noted by #2708, which given the error message you've provided, is what you have installed. Update to the latest release of this package, and downgrade the ORM to 2.18.

Is there any open PR or active development plans to support ORM 3.0?

To answer myself and any future onlooker, there are ongoing developments, specially @mbabker 's:

#2708
main...mbabker:DoctrineExtensions:orm-3-merge

[mbabker]

For anyone stumbling here, or any other of the plethora of issues about ORM 3 compatibility, if anyone's got the time and energy to work on a solution that retains backward compatibility with the existing dependencies (so should still support PHP 7.4, should support both ORM 2.x and 3.x, etc.), unless there's an explicit agreement to change things, feel free to do so. Keep in mind this package has ~50,000 daily installs, and up to the 3.14 release, PHP 7.4 users accounted for a not-so-insignificant number of those installs. IMO it is fair to ask that folks look at the metrics and balance those against "well this version is EOL so you should have dropped support for it already".

I've been doing what I can with my free time, I'm not working on this (or most of my OSS contributions really) under any form of sponsorship or paid company time, so I personally don't have a concrete answer to give as far as "here's when you can expect me to do this to get ORM 3.x support finalized" goes; when my time and mental health allows, I'll support where I can.

As for open PRs, #2784 works if you approach the problem without any B/C constraints, and last I looked at #2786 it seemed like it was incomplete. Also keep in mind that any PRs working on ORM 3.x compatibility don't necessarily need to be one massive PR with everything included (see a bunch of the smaller PRs I've done that have worked on some specific forward-compatibility scenarios), so a PR that takes care of updating places in the code that currently expect arrays but would receive this new Doctrine\ORM\Mapping\FieldMapping value object when ORM 3.x is installed would also be helpful as it's still helping get one step closer to full ORM 3.x support.

[franmomu]

Closing here as compatibility with ORM 3 has been added with the work of @mbabker, you can start testing it using the main branch