Extensiones de la Doctrine: Timestampable

Hey @Sjoerd-N!

Hmm, yea, that makes sense. Doctrine ORM 3 just came out, and one of the biggest changes is that the mapping changed from an array to FieldMapping. That's a nice change, but a bunch of libraries on the web are still updating to work with V3. It looks like the latest version of this library actually restricts using ORM 3 - https://github.com/doctrine-extensions/DoctrineExtensions/releases/tag/v3.15.0 - because they're not ready for it yet. But I'm not sure what the status is.

So, the fix is to downgrade doctrine/orm to ^2.18 in your composer.json file (or add this line if it's not there).

Cheers!

great! that worked ^^

Hey guys!

No error? That's even better ;) Well, most probably you have a fresher Doctrine migrations package installed, or you have a fresher MariaDB server version, or even both :) I see your app was able to generate a single query migration, i.e. it's was optimized in comparison to the migration in the video. In other words, migrations might be slightly different because of different versions. So, as long as this migration works for you - that's great, you can ignore hunting about that error ;)

Cheers!

Same for me... My project ist connected to a local MariaDB, but this should not have any effect?!

Hey Remy,

I replied with my thoughts about this difference here: https://symfonycasts.com/screencast/symfony-doctrine/timestampable#comment-28049

Cheers!

It’s also a Maria DB on my side.

Benoit

Hey Ssi-anik,

Thank you for the tip! I personally didn't try this but I'll believe you that it works :)

Cheers!

Hey Francois,

Well, it may depend on the DB server you're using.

unless absolutely required, entries should be nullable

Sounds good. Though that's not necessary actually, e.g. some fields, like string, may just be an empty string. Or it may just be 0 instead of NULL, so it mostly depends on your needs.

but, if nullable, they should have a default value in the entity (for instance an empty string for a text type, or null in general)

Default value in the entity might be a good idea to avoid "field not initilized" error. Well, you can play without a default value and you will see if you get an error because of it or no.

Cheers!

Finally I had to create my own trait to set the updatedAt value with PreFlush LifecycleCallback in the parent entity. It fires well the preUpdate Event but even when no change was made at all… If someone has another idea, it will be appreciated. Thanks !

hey @Cyril

It's pretty hard to get some advice without seeing how listener was implemented IIRC, you can check if there were some changes on entity, there is method on event argument to check the change set

Cheers!

Hi,
Here is my solution with an EventSubscriber. Maybe it could help someone else as it works for me.

//src/EventListener/TimestampCollectionParentEntitySubscriber.php

<?php

namespace App\EventListener;

use Doctrine\ORM\Events;
use Doctrine\ORM\EntityManagerInterface;
use Doctrine\Persistence\Event\LifecycleEventArgs;
use Doctrine\Bundle\DoctrineBundle\EventSubscriber\EventSubscriberInterface;

class TimestampCollectionParentEntitySubscriber implements EventSubscriberInterface
{
    public function __construct(private EntityManagerInterface $em) {
    }

    public function getSubscribedEvents(): array
    {
        //don't use "pre" events as it creates an infinite loop...
        return [            
            Events::postPersist,
            Events::postRemove,
            Events::postUpdate,            
        ];
    }
    
    public function postPersist(LifecycleEventArgs $args): void
    {
        $this->_timestampParentEntity($args);
    }
    public function postUpdate(LifecycleEventArgs $args): void
    {
        $this->_timestampParentEntity($args);
    }
    public function postRemove(LifecycleEventArgs $args): void
    {
        $this->_timestampParentEntity($args);
    }

    private function _timestampParentEntity($args) {
    
        // During a Doctrine Event, the EntityManager gives us this array :
        // em->getUnitOfWork()->getIdentityMap() which looks like
        // [
        //    'classname1' => [id1 => entity1],
        //    'classname2' => [id2 => entity2]
        // ]
        // and its first element (entity1) is the highest entity in the form
        // => this is the entity we want to timestamp
       
        $identityMap = $this->em->getUnitOfWork()->getIdentityMap();
        if($identityMap !== []) {
            foreach(array_slice($identityMap, 0, 1, true) as $parentClassname => $parentArray);
            foreach(array_slice($parentArray, 0, 1, true) as $parentId => $parent);
            if($args->getObject() !== $parent && method_exists($parent, 'setUpdatedAt')) {
                //here, the Event does NOT concern the parent itself BUT necessarily a child collection inside the parent => let's timestamp the parent!
                $parent->setUpdatedAt(new \DateTime());
                //then flush
                $this->em->flush();
            }
        }
    }
}

Honestly I'm not sure about your way, I think it can be done with less code and without several foreach blocks, as I understand the collection is some sort of One-To-Many relation, so you can just make a doctrine listener and create some sort of ParentTimeStampableInterface and check if persisted/updated/deleted entity is instance of this interface then simple getParent() method to get parent entity and make your changes

or maybe I'm missing something =)

Cheers.

Of course there are other ways (array_values, for example) to get the parent entity which is a bit deeply wrapped in $identityMap which is an associative array.

But anyways, I don't understand your approach as I'm not very familiar with interfaces :-(
If you ever have time to spend in it, a small example of code will be appreciated!

Thanks

Hey @Georg-L!

Yes, when things go wrong with migrations, life gets tricky :p. And part of that can't be avoided: if we get surprised by a failing migration when deploying, it means something unexpected happened. Then, to make matters worse, fixing it may not be as simple as running the "down" method. For example, suppose you have a migration that executes 3 SQL statements. When you run it, the 1st is successful, but the 2nd fails (and so the 3rd also didn't run). If you ran the down() method, it will likely also fail because usually those methods try to do up() in reverse. So, for example, if the 3rd statement in up was a CREATE TABLE foo, then the 1st statement in down() will be DROP TABLE foo... which will fail, because foo was never created.

So, as you can see - a big mess when things fail! But sometimes running down WILL help. And you DID use the correct command. My guess is that it's failing due to the reason I described above.

When this happens to me (it's rare, but bad things DO happen), I debug it by hand. There's simply no automatic way to know exactly how a migration failed (did none of the statements run successfully? Or some of them?). In this situation, doctrine:schema:update can be your friend:

php bin/console doctrine:schema:update --dump-sql

That'll show you what is "missing" from your production database. It might be enough to execute those:

php bin/console doctrine:schema:update --force

Or, more likely, I may copy those commands and "adapt" them quickly, and run them manually. For example, suppose, like in this video, I'm missing a new column that does NOT allow null... but that failed because of a not null violation. To fix this, I would copy the SQL statement from doctrine:schema:update, change it to "YES" allow NULL temporarily, then run that. At that point, your site will probably start working again, and you can figure out your next steps. Probably you'll run some SQL to give all of the existing records some value for the column, and THEN run another SQL query to change the column from "yes" allows null to "NOT" allow null. Finally, after fixing things by hand, you may need to tell Doctrine manually that the migration that failed "did run" (since you have basically completed that migration manually) so that it won't try to run it again on the next deploy. You can do that with the doctrine:migrations:version command, followed by the version.

Phew! Let me know if this helps - it is always an ugly situation when this happens!

Cheers!

Hey Rayn,
thank you so much for your answer. This is really very helpful. Yeah, failing migrations ar ugly, brrrr. I have some experience with phinx. I can tell you, that this can also be messed up, if you try hard enough ;)

So thanks to you, I have a toolset to handle these situations.

See U.

btw.
I love this course. You did a great job. Thank you.

Happy this was helpful - and thanks for the kind words ❤️

Hey Michael,

Hm, maybe? That trait gives you some ready-to-use functionality. You can do it yourself, with createdAt it's pretty easy, you can set it in the constructor. With the updatedAt - a bit more complex, you need to add a listener to track when the entity is actually updated. So, at least it save your time.

Cheers!

Hey JnahDev,

Did you download the course code, or are you following this tutorial on your own? It seems like your project is expecting "annotations" but in Symfony 6 those were removed and you should use PHP attributes

No I'm following the tutorial on my own, maybe I need to download the source code and continue other chapters.
Thank you MolloKhan.

yes, that's how we recommend following our tutorials, although you can do it on your own, but of course, you'll find problems like this along the way

I fixed this bug by adding annotations.yaml in config/routes, but I don't understand why this problem occurs.

controllers:
  resource: ../../src/Controller/
  type: annotation

kernel:
  resource: ../../src/Kernel.php
  type: annotation

After I installed Doctrine bundle I encountered this bug.

Hey Mark,

I'm afraid that's not possible if you use the entity trait. For that purpose, you'll have to add each property to your entity like this

    #[Gedmo\Timestampable(on: 'create')]
    #[ORM\Column(name: 'table_name', type: 'datetime')]
    private ?\DateTimeInterface $createdAt = null;

I hope it helps. Cheers!

This error was fixed in version 6.2.3

Sorry for the late reply!

Nice catch! Thank you TS

By the way, in case you're interested in helping a bit further. We have a GitHub link on each chapter script where you can submit change requests

Cheers!