Ocurre muchas veces que a la hora de escribir el modelo de datos para nuestro proyecto necesitamos relaciones de n:n entre las distintas entidades. Un ejemplo simple de esto nos lo podemos encontrar en el plugin sfDoctrineGuardPlugin, donde entre los permisos (sfGuardPermission) y los grupos (sfGuardGroup) se establece una relación de este estilo (fGuardGroupPermission). El archivo schema.yml sería éste (copiado directamente del plugin):
sfGuardGroup:
actAs: [Timestampable]
columns:
name:
type: string(255)
unique: true
description: string(1000)
relations:
Users:
class: sfGuardUser
refClass: sfGuardUserGroup
local: group_id
foreign: user_id
foreignAlias: Groups
Permissions:
class: sfGuardPermission
local: group_id
foreign: permission_id
refClass: sfGuardGroupPermission
foreignAlias: Groups
sfGuardPermission:
actAs: [Timestampable]
columns:
name:
type: string(255)
unique: true
description: string(1000)
sfGuardGroupPermission:
options:
symfony:
form: false
filter: false
actAs: [Timestampable]
columns:
group_id:
type: integer
primary: true
permission_id:
type: integer
primary: true
relations:
Group:
class: sfGuardGroup
local: group_id
onDelete: CASCADE
Permission:
class: sfGuardPermission
local: permission_id
onDelete: CASCADESi nos fijamos, podemos ver que a la hora de definir la tabla de la relación (sfGuardGroupPermission) aparece un línea options muy interesante:
sfGuardGroupPermission:
options:
symfony:
form: false
filter: falseCon esto evitamos que a la hora de ejecutar la tarea symfony doctrine:build --all se generen las clases de los formularios y los filtros para esa tabla. Fijaros que sigue siendo necesario tener las clases del modelo ya que al trabajar con una ORM (Doctrine) necesitamos mapear a objetos todas las tablas de nuestro modelo.
Después de casi 3 años trabajando con symfony me resulta curioso ver como no pasa el día en el que symfony me sorprenda con cosas de este estilo.
