Saber quién modificó un registro y cuándo puede salvarte de muchos dolores de cabeza al trabajar con bases de datos. Con Spring Data JPA puedes activar la auditoría de entidades en pocos pasos usando AuditingEntityListener, lo que te permite registrar fechas de creación y modificación de manera casi transparente.

Esta guía te muestra cómo habilitar la auditoría JPA en un proyecto Spring Boot, anotar tus columnas con @CreatedDate y @LastModifiedDate, y reutilizar la lógica con una superclase @MappedSuperclass. Es contenido pensado para desarrolladores backend que quieren rastrear cambios sin escribir código repetitivo.

¿Cómo activar la auditoría JPA en Spring Boot?

Lo primero es decirle a tu aplicación que va a trabajar con auditoría. Para eso, abre la clase principal anotada con @SpringBootApplication, donde ya tienes @EnableJpaRepositories, y añade la anotación @EnableJpaAuditing [0:55].

Con esa anotación, Spring queda listo para detectar los campos auditables que definas en tus entities. No necesitas configuración adicional en application.properties ni dependencias extra si ya usas spring-boot-starter-data-jpa.

¿Qué hace @EnableJpaAuditing? Activa el soporte de auditoría de Spring Data JPA en toda la aplicación, permitiendo que anotaciones como @CreatedDate y @LastModifiedDate funcionen automáticamente sobre tus entidades.

¿Cómo anotar un entity para que sea auditable?

El siguiente paso ocurre dentro del entity que quieres auditar, en este caso PizzaEntity. Aquí entra en juego @EntityListeners, que recibe como parámetro la clase AuditingEntityListener.class [1:25].

Esa anotación le dice a JPA que escuche los eventos del ciclo de vida del entity (insert, update) y dispare la lógica de auditoría. Es el puente entre tu entidad y el motor de auditoría de Spring Data.

¿Qué columnas necesito agregar?

Dentro del entity vas a crear dos atributos de tipo LocalDateTime:

• createdDate, mapeado a la columna created_date con la anotación @CreatedDate.
• modifiedDate, mapeado a la columna modified_date con la anotación @LastModifiedDate.

Ambas anotaciones provienen del paquete de Spring Data, no de JPA estándar [3:00]. Cuando levantas la aplicación, Hibernate detecta los nuevos campos y crea automáticamente las columnas en la tabla.

¿Cómo verifico que la auditoría funciona?

Al consultar las pizzas existentes en MySQL, las nuevas columnas aparecen con valor NULL, porque los registros se crearon antes de incorporar la auditoría. Pero al hacer un PUT desde Postman para cambiar el nombre de la pizza con id 7 de "Mother Heart" a "Mother Heart 2", la respuesta llega con estatus 200 y la columna modified_date se actualiza sola en la base [4:25].

Lo mismo pasa al crear un registro nuevo: created_date se llena automáticamente, sin que tengas que pasar esos valores en el body de la petición.

¿Cómo evitar repetir las columnas de auditoría en cada entity?

Si tu proyecto tiene varias tablas que necesitan auditoría, copiar las dos columnas en cada entity se vuelve tedioso. La solución elegante es crear una superclase abstracta que centralice esos campos.

Dentro del paquete entity, crea una clase llamada AuditableEntity y mueve allí los atributos createdDate y modifiedDate junto con sus anotaciones. La pieza clave es @MappedSuperclass, que indica a JPA que esta clase no es una entidad por sí misma, pero sus atributos deben mapearse en las tablas de las clases hijas [6:30].

Después, en PizzaEntity simplemente declaras la herencia:

java public class PizzaEntity extends AuditableEntity

Y mantienes el @EntityListeners(AuditingEntityListener.class) sobre la entidad concreta. Con eso, cualquier futuro entity que herede de AuditableEntity tendrá la capacidad de auditoría sin duplicar código.

¿Para qué sirve @MappedSuperclass? Permite definir una clase padre cuyos atributos se heredan y mapean a las tablas de las clases hijas, sin que la superclase tenga su propia tabla.

¿Cómo ocultar los campos de auditoría en la respuesta JSON?

Por defecto, createdDate y modifiedDate viajan en la respuesta del API aunque no los envíes en la petición. Si esos campos son útiles solo para auditoría interna y no para el cliente, anota cada atributo con @JsonIgnore [5:35].

Cuando los mueves a AuditableEntity, los campos dejan de aparecer en el JSON de respuesta de forma natural, porque el serializador trabaja sobre la estructura visible de la entidad concreta.

¿Qué resultado obtienes con esta configuración?

Después de aplicar la herencia y volver a ejecutar la aplicación, una actualización al registro "Mother Heart" deja la columna modified_date con la hora exacta del cambio (por ejemplo, 11:07 y luego 11:11 en pruebas consecutivas). Al insertar un nuevo registro como "Popeye", aparecen ambas fechas: creación y modificación [8:30].

Esto te da trazabilidad completa con tres elementos mínimos:

1. @EnableJpaAuditing en la clase principal.
2. @EntityListeners(AuditingEntityListener.class) en el entity.
3. @CreatedDate y @LastModifiedDate sobre los atributos LocalDateTime.

Y si quieres registrar más detalles, como el usuario que hizo el cambio, vas a necesitar un listener personalizado. ¿Ya tienes claro cómo aplicar esto en tu proyecto? Cuéntame en los comentarios qué tablas vas a auditar primero.