Slugs únicos con validación lógica y física

Si trabajas con Symfony y necesitas que un campo como el slug nunca se repita, debes aplicar dos capas de protección: una validación lógica en la entidad y una validación física en la base de datos. Así garantizas búsquedas confiables y evitas duplicados que rompan tu lógica de negocio.

La idea es simple: cuando vas a buscar contenido por slug, ese valor tiene que ser único. Si dos categorías comparten el mismo slug, tu sistema no sabe cuál mostrar. Y aquí viene lo interesante: muchas veces creemos que con validar en el formulario basta, pero la base de datos sigue aceptando duplicados si no la configuras.

¿Qué es una validación lógica y cómo se aplica en una entidad de Symfony?

La validación lógica vive en el código. Es la primera barrera que detiene al usuario antes de tocar la base de datos.

Para activarla en la entidad de categorías, importa la clase desde Symfony\Bridge\Doctrine\Validator\Constraints\UniqueEntity y agrégala como anotación encima de la clase, indicando el campo a validar:

php #[UniqueEntity(fields: ['slug'])]

Este componente ya viene incluido si instalaste el panel administrativo EasyAdmin. Puedes confirmarlo abriendo vendor/easycorp/.../composer.json y revisando las dependencias: ahí aparecen el sistema de traducción y el de validación.

¿Qué hace UniqueEntity en Symfony? Es una restricción que verifica, antes de guardar, si ya existe un registro con el mismo valor en el campo indicado. Si lo encuentra, lanza un error de validación.

Después de aplicar el cambio, al intentar crear una segunda categoría con slug php, el formulario responde que ese valor ya se ha utilizado. Misma lógica para publicaciones: importa la clase, agrega la anotación con slug y guarda.

¿Por qué necesito también una validación física en la base de datos?

La validación lógica protege desde el formulario, pero si alguien inserta directamente en la tabla por SQL, la base de datos acepta el duplicado sin reclamar. Por eso necesitas una restricción física.

En la entidad, ubica la propiedad slug y modifica la columna agregando unique: true después del largo:

php #[ORM\Column(length: 255, unique: true)] private ?string $slug = null;

Haz lo mismo en la entidad de publicaciones. Estos cambios todavía no impactan tu base de datos: necesitas generar una migración que los ejecute.

¿Cómo creo y ejecuto la migración para el campo único?

Desde la terminal ejecuta el comando que detecta los cambios en las entidades:

bash php bin/console make:migration

Symfony genera un archivo de migración que indica que va a crear un índice único sobre el campo slug tanto en la tabla de categorías como en la de publicaciones. Revísalo antes de aplicarlo.

Luego ejecuta la migración con el comando que el propio sistema te sugiere, responde que sí cuando pregunte la confirmación y listo: el cambio físico ya está en la base de datos.

Para comprobarlo, intenta insertar dos veces el mismo slug directamente en la tabla. La base de datos responde con un error de entrada duplicada. Si revisas la estructura de la tabla, verás que el campo slug aparece marcado como único.

¿Cuál es la diferencia entre validación lógica y validación física? La lógica vive en el código y bloquea desde la aplicación con UniqueEntity. La física vive en la base de datos como un índice único y bloquea cualquier inserción, incluso por SQL directo.

¿Cuándo conviene usar ambas validaciones en un proyecto Symfony?

La recomendación práctica es activar ambas. La validación lógica te da mensajes amigables al usuario en el formulario; la validación física garantiza integridad pase lo que pase, incluso si alguien manipula la base de datos por fuera de la aplicación.

Piénsalo así:

• La validación lógica es como el portero del edificio que pregunta a quién visitas.
• La validación física es la cerradura de la puerta del departamento.
• Si tienes solo una, alguien podría colarse por el otro lado.

Para verificar qué archivos modificaste durante todo el proceso, ejecuta git status. Verás las dos entidades editadas y la nueva migración creada. Son pocos cambios para una protección que evita errores difíciles de rastrear más adelante.

¿Tú prefieres aplicar siempre ambas validaciones o has tenido casos donde solo usas una? Cuéntame en los comentarios cómo manejas la unicidad de campos en tus proyectos.