Crear objetos incrustados
Keep on Learning!
If you liked what you've learned so far, dive in! Subscribe to get access to this tutorial plus video, code and script downloads.
With a Subscription, click any sentence in the script to jump to that part of the video!
Login Subscribe¿Es posible crear un DragonTreasure totalmente nuevo cuando creamos un usuario? Como... ¿en lugar de enviar el IRI de un tesoro existente, enviamos un objeto?
¡Vamos a intentarlo! Primero, cambiaré esto por un correo electrónico y un nombre de usuario únicos. Después, paradragonTreasures, borra esos IRI y, en su lugar, pasa un objeto JSON con los campos que sabemos que son obligatorios. ¡Nuestro nuevo usuario dragón acaba de conseguir una copia de GoldenEye para N64! Legendario. Añade un description... y un value.
En teoría, ¡este cuerpo JSON tiene sentido! ¿Pero funciona? Pulsa "Ejecutar" y... ¡no! Bueno, todavía no. ¡Pero conocemos este error!
No se permiten documentos anidados para el atributo
dragonTreasures. Utiliza IRI en su lugar.
Cómo hacer que dragonTreasures acepte objetos JSON
Dentro de User, si nos desplazamos hacia arriba, la propiedad $dragonTreasures es escribible porque tiene user:write.
| // ... lines 1 - 22 | |
| class User implements UserInterface, PasswordAuthenticatedUserInterface | |
| { | |
| // ... lines 25 - 51 | |
| (['user:read', 'user:write']) | |
| private Collection $dragonTreasures; | |
| // ... lines 54 - 170 | |
| } |
Pero no podemos enviar un objeto para esta propiedad porque no hemos añadido user:write a ninguno de los campos dentro de DragonTreasure. Arreglemos eso.
Queremos poder enviar $name, así que añade user:write... Me saltaré $descriptionpero haré lo mismo con $value. Ahora busca setTextDescription() que es la descripción real. Añade user:write aquí también.
| // ... lines 1 - 55 | |
| class DragonTreasure | |
| { | |
| // ... lines 58 - 63 | |
| (['treasure:read', 'treasure:write', 'user:read', 'user:write']) | |
| // ... lines 65 - 67 | |
| private ?string $name = null; | |
| // ... lines 69 - 79 | |
| (['treasure:read', 'treasure:write', 'user:read', 'user:write']) | |
| // ... lines 81 - 82 | |
| private ?int $value = 0; | |
| // ... lines 84 - 138 | |
| (['treasure:write', 'user:write']) | |
| public function setTextDescription(string $description): self | |
| { | |
| // ... lines 142 - 144 | |
| } | |
| // ... lines 146 - 214 | |
| } |
Vale, en teoría, ahora deberíamos poder enviar un objeto incrustado. Si nos dirigimos y lo intentamos de nuevo... ¡obtenemos un error 500!
Se ha encontrado una nueva entidad a través de la relación
User#dragonTreasures
Persistencia de una relación de entidad en cascada
¡Esto es genial! Ya sabemos que cuando envías un objeto incrustado, si incluyes@id, el serializador recuperará primero ese objeto y luego lo actualizará. Pero si no tienes @id, creará un objeto totalmente nuevo. Ahora mismo, está creando un objeto nuevo,... pero nada le ha dicho al gestor de entidades que lo persista. Por eso obtenemos este error.
Para solucionarlo, necesitamos persistir en cascada esta propiedad. En User, en la opciónOneToMany para $dragonTreasures, añade una opción cascade establecida en ['persist'].
| // ... lines 1 - 22 | |
| class User implements UserInterface, PasswordAuthenticatedUserInterface | |
| { | |
| // ... lines 25 - 50 | |
| #[ORM\OneToMany(mappedBy: 'owner', targetEntity: DragonTreasure::class, cascade: ['persist'])] | |
| // ... line 52 | |
| private Collection $dragonTreasures; | |
| // ... lines 54 - 170 | |
| } |
Esto significa que si estamos guardando un objeto User, debería persistir mágicamente cualquier $dragonTreasures que haya dentro. Y si lo probamos ahora... ¡funciona! Es increíble! Y aparentemente, nuestro nuevo tesoro id es 43.
Abramos una nueva pestaña del navegador y naveguemos hasta esa URL... más .json... en realidad, hagamos .jsonld. ¡Estupendo! Vemos que el owner está establecido para el nuevo usuario que acabamos de crear.
¿Cómo se estableció el propietario? De nuevo: Los métodos inteligentes
Pero... ¡aguanta! No enviamos el campo owner en los datos del tesoro... entonces, ¿cómo se estableció ese campo? Bueno, en primer lugar, tiene sentido que no enviáramos un campo owner para el nuevo DragonTreasure... ¡ya que el usuario que será su propietario ni siquiera existía todavía! Vale, entonces, ¿pero quién estableció el owner?
Entre bastidores, el serializador crea primero un nuevo objeto User. Después, crea un nuevo objeto DragonTreasure. Finalmente, ve que el nuevo DragonTreasureaún no está asignado al User, y llama a addDragonTreasure(). Cuando lo hace, el código de aquí abajo establece el owner: tal y como vimos antes. Así que nuestro código bien escrito se está ocupando de todos esos detalles por nosotros.
| // ... lines 1 - 22 | |
| class User implements UserInterface, PasswordAuthenticatedUserInterface | |
| { | |
| // ... lines 25 - 149 | |
| public function addDragonTreasure(DragonTreasure $treasure): self | |
| { | |
| if (!$this->dragonTreasures->contains($treasure)) { | |
| $this->dragonTreasures->add($treasure); | |
| $treasure->setOwner($this); | |
| } | |
| return $this; | |
| } | |
| // ... lines 159 - 170 | |
| } |
Añadir la restricción válida
De todos modos, quizá recuerdes de antes que en cuanto permitimos que un campo de relación envíe datos incrustados... tenemos que añadir una cosita. No lo haré, pero si enviáramos un campo name vacío, se crearía un DragonTreasure... con unname vacío, aunque, por aquí, si nos desplazamos hasta la propiedad name, ¡es obligatorio! Recuerda: cuando el sistema valide el objeto User, se detendrá en$dragonTreasures. No validará también esos objetos. Si quieres validarlos, añade #[Assert\Valid].
| // ... lines 1 - 22 | |
| class User implements UserInterface, PasswordAuthenticatedUserInterface | |
| { | |
| // ... lines 25 - 52 | |
| private Collection $dragonTreasures; | |
| // ... lines 55 - 171 | |
| } |
Ahora que tengo esto, para comprobar que funciona, pulsa "Ejecutar" y... ¡genial! Obtenemos un código de estado 422 que nos indica que name no debería estar vacío. Voy a volver a ponerlo.
Enviar objetos incrustados y cadenas IRI al mismo tiempo
Ahora sabemos que podemos enviar cadenas IRI u objetos incrustados para una propiedad de relación, suponiendo que hayamos configurado los grupos de serialización para permitirlo. E incluso podemos mezclarlos.
Digamos que queremos crear un nuevo objeto DragonTreasure, pero también vamos a robar, tomar prestado, un tesoro de otro dragón. Esto está totalmente permitido. ¡Mira! Cuando pulsamos "Ejecutar"... obtenemos un código de estado 201. Esto devuelve los identificadores de tesoro 44 (que es el nuevo) y 7, que es el que acabamos de robar.
Vale, ya sólo nos queda un capítulo sobre el manejo de las relaciones. Veamos cómo podemos quitar un tesoro a un usuario para eliminar ese tesoro. Eso a continuación.
Do I get it right that i'ts not possible to update an embedded resource?
I tried to call patch with this:
but instead it removed the old one and created the new one completly ignoring @id. As there was no video on updating related entities I get you can only add, assign, delete embedded objects?