Adding createdAt and updatedAt Timestampable Fields

UPGRADE! Check out the newest version of this tutorial

Adding createdAt and updatedAt Timestampable FieldsΒΆ

Let’s do more magic! I always like to have createdAt and updatedAt fields on my database tables. A lot of times, this helps me debug any weird behavior I may see in the future.

The DoctrineExtensions library does this for us. It’s called timestampable, enable it in config.yml:

# app/config/config.yml
# ...

            sluggable: true
            timestampable: true

Head to the timestampable section of the documentation to see how this works. We already have the Gedmo annotation, so just copy in the created and updated properties and rename them to createdAt and updatedAt, just because I like those names better:

// src/Yoda/EventBundle/Entity/Event.php
// ...

 * @Gedmo\Timestampable(on="create")
 * @ORM\Column(type="datetime")
private $createdAt;

 * @Gedmo\Timestampable(on="update")
 * @ORM\Column(type="datetime")
private $updatedAt;

And now we’ll generate getter methods for these:

 * @return \DateTime
public function getCreatedAt()
    return $this->createdAt;

 * @return \DateTime
public function getUpdatedAt()
    return $this->updatedAt;

We can also add setter methods if we want, but we don’t need them: the library will set these for us!

Next, update the database schema to add the two new fields and then reload the fixtures:

php app/console doctrine:schema:update --force
php app/console doctrine:fixtures:load

Query for the events again:

php app/console doctrine:query:sql "SELECT * FROM yoda_event"

Nice! Both the createdAt and updatedAt columns are properly set. To avoid sadness and regret add these fields to almost every table.

Leave a comment!

  • 2017-09-07 Diego Aguiar

    Hey Pascal Q (pascal.)

    Yes, it still works, you can use it safely. You can find more information here:


  • 2017-09-07 Pascal Q (pascal.)

    The bundle introduced here is not available for Symfony 3.x, is it?

  • 2017-04-05 Victor Bocharsky

    Hey Dimitry,

    Agree! And there's another approach: if you use migrations, you can do some extra queries there and do not use `options={"default"="1970-01-01 00:00:00"} ` or `nullable=true` at all ;)


  • 2017-04-04 Dimitry K

    Hey Victor,

    settings `nullable=true` is a good option as well (and shorter thus lazier). However I chose _not_ to use it and use "default" approach, because then I don't have to add to my codebase any special cases for when `createdAt` or `updatedAt` is null.

  • 2017-04-03 Victor Bocharsky

    Hey Dimitry,

    You're right, thank you for sharing this! There's also another solution: use "nullable=true" for those fields.


  • 2017-03-31 Dimitry K

    If you try to add `createdAt` and `updatedAt` fields to an existing database table which already has data (thus you don't want to purge and recreate schema), you will run into those errors:

    SQLSTATE[22007]: Invalid datetime format: 1292 Incorrect datetime value: '0000-00-00 00:00:00' for column 'created_at' at row 1

    and this:

    An exception occurred while executing 'ALTER TABLE building ADD created_at DATETIME NOT NULL, ADD updated_at DATETIME NOT NULL':
    SQLSTATE[22007]: Invalid datetime format: 1292 Incorrect datetime value: '0000-00-00 00:00:00' for column 'created_at' at row 1

    To avoid this problem you can communicate to MySQL default value of those columns by declaring fields like this:

    @ORM\Column(name="updated_at", type="datetime", options={"default"="1970-01-01 00:00:00"})
  • 2015-09-10 weaverryan
  • 2015-09-10 guest

    there is a typo in header: