Tag Archives: persistir

Restricciones en las asociaciones ORM de Doctrine2

Es importante conocer las restricciones que Doctrine2 presenta cuando tenemos que elaborar asociaciones entre Entidades. Copiado de la Documentación de Doctrine2:

Because we only work with collections for the references we must be careful to implement a bidirectional reference in the domain model. The concept of owning or inverse side of a relation is central to this notion and should always be kept in mind. The following assumptions are made about relations and have to be followed to be able to work with Doctrine 2. These assumptions are not unique to Doctrine 2 but are best practices in handling database relations and Object-Relational Mapping.

  • Changes to Collections are saved or updated, when the entity on the owning side of the collection is saved or updated.
  • Saving an Entity at the inverse side of a relation never triggers a persist operation to changes to the collection.
  • In a one-to-one relation the entity holding the foreign key of the related entity on its own database table is always the owning side of the relation.
  • In a many-to-many relation, both sides can be the owning side of the relation. However in a bi-directional many-to-many relation only one is allowed to be.
  • In a many-to-one relation the Many-side is the owning side by default, because it holds the foreign key.
  • The OneToMany side of a relation is inverse by default, since the foreign key is saved on the Many side. A OneToMany relation can only be the owning side, if its implemented using a ManyToMany relation with join table and restricting the one side to allow only UNIQUE values per database constraint.

Consistency of bi-directional references on the inverse side of a relation have to be managed in userland application code. Doctrine cannot magically update your collections to be consistent.

Entendiendo la asociaciones Many-To-One y One-To-Many

El texto está claro pero me queda la siguiente duda, a partir de lo documentado sobre una relación Many-To-One Unidirectional: El lado Many es el owning side por qué guarda la clave foránea. En el ejemplo facilitado, una dirección puede pertenecer a diferentes usuarios, y la Entidad Usuario podrá acceder a la Entidad Dirección. Pero desde la Entidad Dirección no se podrá acceder a los usuarios que la tienen asignada. Por ese motivo se llama Unidireccional. A la hora de persistir un objeto Dirección, no se pueden persistir objetos Usuario, ya que no dispone de asociación en ese sentido, es decir, un objeto Dirección no guarda en su instancia ningún Usuario.

En el caso de la relación One-To-Many Bidirectional, se están generando dos relaciones. Una One-To-Many desde Producto a Característica, y otra Many-To-One desde Característica a Producto. El owning side aquí será el lado Característica, por qué guarda la clave foránea en la tabla de la BDD. En la persistencia se entiende que cuando se crea una Característica se asigna a qué Producto pertenece. Si yo creo un nuevo Producto y una nueva Característica, y le asigno el Producto a la Característica y persisto la Característica, en la BDD se guardan ambos. Y entiendo que si en cambio asigno la nueva Característica al Producto y persisto el Producto, sólo se guardaría éste, pero sí se guarda la Característica (¿?).