Desarrollo de módulos para PrestaShop con Doctrine puede chocar con un problema habitual y frustrante: el error SQLSTATE 42S02 Base table or view not found cuando la tabla existe en la base de datos pero lleva un prefijo dinámico como ps_ o shop_ que Doctrine no tiene en cuenta por defecto.
La causa es sencilla: PrestaShop almacena el prefijo de tablas en la constante _DB_PREFIX_ y cada instalación puede usar un valor distinto. Si las entidades Doctrine se definen con nombres sin prefijo Doctrine buscará tablas sin ese prefijo y fallará. Evitar hardcodear el prefijo en las anotaciones es imprescindible para mantener compatibilidad y buenas prácticas.
La solución robusta consiste en interceptar la carga de metadata de Doctrine mediante un event subscriber que antepone dinámicamente el prefijo de PrestaShop a los nombres de tabla y a las tablas intermedias de relaciones. Conceptualmente los pasos son estos:
1) Crear un Doctrine event subscriber que escuche el evento loadClassMetadata y, para las entidades de tu módulo, modifique el nombre de la tabla primaria y las join tables añadiendo el valor de _DB_PREFIX_ cuando no esté ya presente. Limita el alcance comprobando que el namespace de la entidad pertenezca a tu módulo para no interferir con el core ni con otros módulos.
2) Registrar el subscriber como servicio en services.yml con la etiqueta doctrine.event_subscriber y pasarle como argumento el prefijo de base de datos. Esto mantiene la lógica centralizada y reutilizable.
3) Mantener las entidades limpias y definir en las anotaciones solo el nombre base de la tabla, por ejemplo trade_in_request. Con el subscriber activo Doctrine resolverá dinámicamente a ps_trade_in_request o shop_trade_in_request según la instalación.
4) Asegurar que los scripts SQL de instalación usan la variable de prefijo en install.sql mediante la convención {$prefix}tabla para crear las mismas tablas que espera Doctrine.
5) Limpiar cache y reinstalar o resetear el módulo para que los cambios surtan efecto.
Este enfoque además maneja automáticamente tablas de relación ManyToMany transformando trade_in_request_category en {prefix}trade_in_request_category sin intervención manual.
Antes de desplegar realiza pruebas con prefijos distintos en el entorno de test para garantizar consistencia. También verifica que el subscriber no modifique entidades fuera del namespace de tu módulo.
En Q2BSTUDIO somos especialistas en desarrollo de software a medida y aplicaciones a medida y aplicamos prácticas como esta para asegurar módulos y soluciones escalables. Ofrecemos servicios integrales que incluyen inteligencia artificial, ciberseguridad y migraciones a la nube. Si necesitas implementar soluciones a medida podemos ayudarte con Desarrollo de aplicaciones a medida y también con soluciones de inteligencia artificial para empresas.
Palabras clave relacionadas: aplicaciones a medida, software a medida, inteligencia artificial, ciberseguridad, servicios cloud aws y azure, servicios inteligencia de negocio, ia para empresas, agentes IA y power bi. Si buscas un partner que combine experiencia en PrestaShop, arquitecturas basadas en Doctrine y buenas prácticas de despliegue, Q2BSTUDIO puede acompañarte desde el diseño hasta la operación y la seguridad.
Resumen: no hardcodees prefijos; crea un Doctrine event subscriber para anteponer dinámicamente el prefijo de PrestaShop; registra el servicio; ajusta los SQL de instalación; prueba con distintos prefijos; y mantiene el alcance limitado al namespace de tu módulo. Así conseguirás compatibilidad, mantenimiento simplificado y despliegues más predecibles.

.jpg)
