If you liked what you've learned so far, dive in!
Subscribe to get access to this tutorial plus
video, code and script downloads.
With a Subscription, click any sentence in the script to jump to that part of the video!
Login SubscribeMe gusta mucho añadir el comportamiento timestampable a mis entidades. Es cuando tienes propiedades$createdAt
y $updatedAt
que se establecen automáticamente. Simplemente... ayuda a llevar la cuenta de cuándo sucedieron las cosas. Hemos añadido $createdAt
y lo hemos establecido inteligentemente a mano en el constructor. ¿Pero qué pasa con $updatedAt
? Doctrine tiene un impresionante sistema de eventos, y podríamos engancharnos a él para ejecutar un código en la "actualización" que establezca esa propiedad. Pero hay una biblioteca que ya hace eso. Así que vamos a instalarla.
En tu terminal, ejecuta:
composer require stof/doctrine-extensions-bundle
Esto instala un pequeño bundle, que es una envoltura de una biblioteca llamada DoctrineExtensions. Como muchos paquetes, éste incluye una receta. Pero ésta es la primera receta que proviene del repositorio "contrib". Recuerda: Symfony tiene en realidad dos repositorios de recetas. Está el principal, que está estrechamente vigilado por el equipo principal de Symfony. Luego hay otro llamado recipes-contrib
. Hay algunos controles de calidad en ese repositorio, pero está mantenido por la comunidad. La primera vez que Symfony instala una receta del repositorio "contrib", te pregunta si está bien. Voy a decir p
por "sí permanentemente". Luego ejecuta:
get status
¡Impresionante! Ha habilitado un bundle y ha añadido un nuevo archivo de configuración que veremos en un segundo.
Obviamente, este bundle tiene su propia documentación. Puedes buscarstof/doctrine-extensions-bundle
y encontrarla en Symfony.com. Pero la mayor parte de la documentación está en la biblioteca DoctrineExtensions subyacente... que contiene un montón de comportamientos realmente interesantes, incluyendo "sluggable" y "timestampable". Vamos a añadir primero "timestampable".
Primer paso: entra en config/packages/
y abre el archivo de configuración que acaba de añadir. Aquí, añade orm
porque estamos utilizando Doctrine ORM, luego default
, y por último timestampable: true
.
... lines 1 - 2 | |
stof_doctrine_extensions: | |
default_locale: en_US | |
orm: | |
default: | |
timestampable: true |
Esto no hará realmente nada todavía. Sólo activa un oyente de Doctrine que buscará entidades que soporten timestampable cada vez que se inserte o actualice una entidad. ¿Cómo hacemos que nuestro VinylMix
admita timestampable? La forma más sencilla (y la que a mí me gusta hacer) es mediante un rasgo.
En la parte superior de la clase, di use TimestampableEntity
.
... lines 1 - 7 | |
use Gedmo\Timestampable\Traits\TimestampableEntity; | |
... lines 9 - 10 | |
class VinylMix | |
{ | |
use TimestampableEntity; | |
... lines 14 - 124 | |
} |
Eso es todo. ¡Ya hemos terminado! ¡Hora de comer!
Para entender esta magia negra, mantén pulsado "cmd" o "ctrl" y haz clic en TimestampableEntity
. Esto añade dos propiedades: createdAt
yupdatedAt
. Y son campos normales, como el createdAt
que teníamos antes. También tiene métodos getter y setter aquí abajo, igual que tenemos en nuestra entidad.
La magia es este atributo #[Gedmo\Timestampable()]
. Esto dice que
esta propiedad debe establecerse
on:
'update'
y
esta propiedad debe establecerse
on: 'create'
.
Gracias a este rasgo, ¡obtenemos todo esto gratis! Y... ya no necesitamos nuestra propiedadcreatedAt
... porque ya vive en el trait. Así que elimina la propiedad... y el constructor... y aquí abajo, elimina los métodos getter y setter ¡Limpieza!
El trait tiene una propiedad createdAt
como la que teníamos antes, pero además añade un campoupdatedAt
. Así que tenemos que crear una nueva migración para eso. Ya conoces el procedimiento. En tu terminal, ejecuta:
symfony console make:migration
Entonces... vamos a comprobar ese archivo... para asegurarnos de que queda como esperamos. Veamos aquí... ¡sí! Tenemos ALTER TABLE vinyl_mix ADD updated_at
. Y aparentemente la columna created_at
será un poco diferente a la que teníamos antes.
... lines 1 - 12 | |
final class Version20220718170826 extends AbstractMigration | |
{ | |
... lines 15 - 19 | |
public function up(Schema $schema): void | |
{ | |
// this up() migration is auto-generated, please modify it to your needs | |
$this->addSql('ALTER TABLE vinyl_mix ADD updated_at TIMESTAMP(0) WITHOUT TIME ZONE NOT NULL'); | |
$this->addSql('ALTER TABLE vinyl_mix ALTER created_at TYPE TIMESTAMP(0) WITHOUT TIME ZONE'); | |
$this->addSql('ALTER TABLE vinyl_mix ALTER created_at DROP DEFAULT'); | |
$this->addSql('COMMENT ON COLUMN vinyl_mix.created_at IS NULL'); | |
} | |
... lines 28 - 37 | |
} |
Bien, vamos a ejecutarlo:
symfony console doctrine:migrations:migrate
Y... ¡falla!
[...]
column "updated_at" of relation "vinyl_mix" contains null values.
Esto es un Not null violation
... lo cual tiene sentido. Nuestra base de datos ya tiene un montón de registros... así que cuando intentamos añadir una nueva columna updated_at
que no permite valores nulos... se vuelve loco.
Si el estado actual de nuestra base de datos ya estuviera en producción, tendríamos que ajustar esta migración para dar a la nueva columna un valor por defecto para esos registros existentes. Entonces podríamos volver a cambiarla para que no permita nulos. Para saber más sobre el manejo de migraciones fallidas, consulta un capítulo de nuestro tutorial de Doctrine de Symfony 5.
Pero como todavía no tenemos una base de datos de producción que contenga viny_mix
filas, podemos tomar un atajo: eliminar la base de datos y empezar de nuevo con cero filas. Para ello, ejecuta
symfony console doctrine:database:drop --force
para eliminar completamente nuestra base de datos. Y vuelve a crearla con
symfony console doctrine:database:create
En este punto, tenemos una base de datos vacía sin tablas, incluso la tabla de migraciones ha desaparecido. Así que podemos volver a ejecutar todas nuestras migraciones desde el principio. Hazlo:
symfony console doctrine:migrations:migrate
¡Genial! Se han ejecutado tres migraciones: todas con éxito.
De vuelta a nuestro sitio, si vamos a "Examinar mezclas", está vacío... porque hemos vaciado nuestra base de datos. Así que vayamos a /mix/new
para crear la mezcla ID 1... y luego refresquemos unas cuantas veces más. Ahora dirígete a /mix/7
... y sube la nota, lo que actualizará eseVinylMix
.
De acuerdo ¡Veamos si la marca de tiempo ha funcionado! Comprueba la base de datos ejecutando:
symfony console doctrine:query:sql 'SELECT * FROM vinyl_mix WHERE id = 7'
Y... ¡impresionante! El created_at
está configurado y luego el updated_at
está configurado justo unos segundos después de que hayamos votado la mezcla. Funciona. Ahora podemos añadir fácilmente timestampable
a cualquier entidad nueva en el futuro, simplemente añadiendo ese rasgo.
A continuación: vamos a aprovechar otro comportamiento: sluggable. Esto nos permitirá crear URLs más elegantes guardando automáticamente una versión segura de la URL del título en una nueva propiedad.
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!
If someone wants to migrate the newly generated migration without dropping the whole database, add DEFAULT CURRENT_TIMESTAMP(0)::TIMESTAMP WITHOUT TIME ZONE
in your updated_at
column's definition after NOT NULL
and running the migration should work fine.
Hey Ssi-anik,
Thank you for the tip! I personally didn't try this but I'll believe you that it works :)
Cheers!
By adding that trait, are you not effectively coupling your domain to the infrastructure (beyond the necessary and forgivable attributes/annotations for mapping), which should be what you'd want to avoid doing?
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!
Hello,
For some reason, I get an error while installing this bundle the error:
[Semantical Error] The class "Symfony\Contracts\Service\Attribute\Required" is not annotated with @Annotation.
Are you sure this class can be used as annotation?
If so, then you need to add @Annotation to the class doc comment of "Symfony\Contracts\Service\Attribute\Required".
If it is indeed no annotation, then you need to add @IgnoreAnnotation("required") to the class doc comment of method Symfony\Bundle\FrameworkBundle\Controller\AbstractController::setContainer() in {"path":"..\/src\/Controller\/","namespace":"App\Controller"} (which is being imported from "/Users/macbookpro/Documents/symfonycasts/mixed_vinyl/config/routes.yaml"). Make sure there is a loader supporting the "attribute" type.
any help please!!
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.
Hi I really like the automatic CreatedAt and UpdatedAt feature. I am wondering how do I change the column name that is created to store these, I'm thinking I would need to edit the file below and add the Doctrine column name property to the annotation for the protected $createdAt property?
\vendor\gedmo\doctrine-extensions\src\Timestampable\Traits\TimestampableEntity.php
Is there a more "reusable" way, that doesn't modify the file from the package?
Thank you
Mark
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!
Hey!
After installing stof/docrtine-extensions-bundle
Symfony is throwing this error: Call to undefined method Doctrine\Common\Annotations\AnnotationRegistry::registerLoader()
. My version of Symfony is 6.2.1.
Hi, there seems to be a little typo : Instead of "get status" you meant "git status", correct?
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!
// composer.json
{
"require": {
"php": ">=8.1",
"ext-ctype": "*",
"ext-iconv": "*",
"babdev/pagerfanta-bundle": "^3.7", // v3.7.0
"doctrine/doctrine-bundle": "^2.7", // 2.7.0
"doctrine/doctrine-migrations-bundle": "^3.2", // 3.2.2
"doctrine/orm": "^2.12", // 2.12.3
"knplabs/knp-time-bundle": "^1.18", // v1.19.0
"pagerfanta/doctrine-orm-adapter": "^3.6", // v3.6.1
"pagerfanta/twig": "^3.6", // v3.6.1
"sensio/framework-extra-bundle": "^6.2", // v6.2.6
"stof/doctrine-extensions-bundle": "^1.7", // v1.7.0
"symfony/asset": "6.1.*", // v6.1.0
"symfony/console": "6.1.*", // v6.1.2
"symfony/dotenv": "6.1.*", // v6.1.0
"symfony/flex": "^2", // v2.2.2
"symfony/framework-bundle": "6.1.*", // v6.1.2
"symfony/http-client": "6.1.*", // v6.1.2
"symfony/monolog-bundle": "^3.0", // v3.8.0
"symfony/proxy-manager-bridge": "6.1.*", // v6.1.0
"symfony/runtime": "6.1.*", // v6.1.1
"symfony/twig-bundle": "6.1.*", // v6.1.1
"symfony/ux-turbo": "^2.0", // v2.3.0
"symfony/webpack-encore-bundle": "^1.13", // v1.15.1
"symfony/yaml": "6.1.*", // v6.1.2
"twig/extra-bundle": "^2.12|^3.0", // v3.4.0
"twig/twig": "^2.12|^3.0" // v3.4.1
},
"require-dev": {
"doctrine/doctrine-fixtures-bundle": "^3.4", // 3.4.2
"symfony/debug-bundle": "6.1.*", // v6.1.0
"symfony/maker-bundle": "^1.41", // v1.44.0
"symfony/stopwatch": "6.1.*", // v6.1.0
"symfony/web-profiler-bundle": "6.1.*", // v6.1.2
"zenstruck/foundry": "^1.21" // v1.21.0
}
}
Hello,
For some reason, this is what I get in the version file
And I do not get any error message as mentioned in the exercise.
Best regards
Benoit Lorant