Crear objetos incrustados

Curious that SerializedName('description') annotation for setTextDescription method in embedded case doesn't work. Just got when description is filled:

cheeseListings[0].description: This value should not be blank.

request:

  "email": "us21r@example.com",
  "password": "us21r",
  "username": "us21r",
  "cheeseListings": [
    {
        "title": "new cheese",
        "price": 4000,
        "description": "description cheese"
    }
  ]

Hey triemli!

Hmm, is that right? It's certainly possible, but I would be surprised by that. Is it possible that, instead of the field being incorrectly named, there is an issue with the denormalization groups - i.e. so that the setTextDescription() in this User embedded situation is not writable (and so the serializer is simply ignoring the description field and then, since the description property is blank, it fails validation)?

Let me know - I'm curious :).

Cheers!

If I use the next data direct to CheeseListing, so it works:

{
    "title": "new cheese",
    "price": 4000,
    "description": "description cheese"
}

It doesn't work only in case of embedded.

    #[ORM\Column(type: Types::TEXT)]
    #[Groups(['cheese_listing:read', 'user:read', 'user:write'])]
    #[NotBlank]
    private ?string $description = null;
    
    #[Groups(['cheese_listing:write'])]
    #[SerializedName('description')]
    public function setTextDescription(string $description): self
    {
        $this->description = nl2br($description);

        return $this;
    }

Also it works if I just add setDescription() method. So I can make conclusion that #[SerializedName('description')] don't goes being embedded.

Hey @triemli!

Hmm. What happens if you add the user:write group to the setTextDescription() method? I believe that's needed. By using setTextDescription() to set the description property (instead of the normal setDescription()), when a description property is sent to the API, API Platform sees that setTextDescription() should be used and then reads its Groups. It actually doesn't know or care that the description property will ultimately be set. And so, it doesn't read the property's groups.

Anyways, let me know if that fixes it - I hope so. And happy new year!

Cheers!

Just a little side-note if anyone runs into the same issue I did.
The owning side must contain all autogenerated Entity field methods for this to work (at least addEntity and removeEntity method).
In my use case removeEntity was just in the way due to the setEntity(null) issue on required relation.

Expected behaviour (IMO) was for doctrine to complain about cascade persist (2:49) or tell me a required function is missing, but instead it ignored the addEntity method all together and threw no errors.

I'm getting "Cannot create metadata for non-objects." I'm using Symfony 5 here. Not sure where to go with this, Google searches are not helping.

Hey Andrew M.!

Hmm, this is a new one for me too! It looks like this is probably coming from deep in the serializer. Do you have a stack trace on this? What request are you making (e.g. a GET request to some object)? Is there any way to see the data that's being serialized?

Cheers!

Here's the request:

curl -X 'POST' \
  'https://127.0.0.1:8000/api/users' \
  -H 'accept: application/ld+json' \
  -H 'Content-Type: application/ld+json' \
  -d '{
  "email": "use065465r@example.com",
  "password": "654654",
  "username": "2254455",
  "cheeseListings": [
    {
      "title": "Cheese 654654",
      "price": 6587,
      "description": "descknjdn"
    }
  ]
}'

Hi, thanks for the reply. Here's the full trace; it's pretty long.

{
  "@context": "/api/contexts/Error",
  "@type": "hydra:Error",
  "hydra:title": "An error occurred",
  "hydra:description": "Cannot create metadata for non-objects. Got: \"string\".",
  "trace": [
    {
      "namespace": "",
      "short_class": "",
      "class": "",
      "type": "",
      "function": "",
      "file": "/home/andy/Personal/SymfonyCast/SymfonyAPI/api_platform/vendor/symfony/validator/Validator/RecursiveContextualValidator.php",
      "line": 653,
      "args": []
    },
    {
      "namespace": "Symfony\\Component\\Validator\\Validator",
      "short_class": "RecursiveContextualValidator",
      "class": "Symfony\\Component\\Validator\\Validator\\RecursiveContextualValidator",
      "type": "->",
      "function": "validateGenericNode",
      "file": "/home/andy/Personal/SymfonyCast/SymfonyAPI/api_platform/vendor/symfony/validator/Validator/RecursiveContextualValidator.php",
      "line": 516,
      "args": []
    },
    {
      "namespace": "Symfony\\Component\\Validator\\Validator",
      "short_class": "RecursiveContextualValidator",
      "class": "Symfony\\Component\\Validator\\Validator\\RecursiveContextualValidator",
      "type": "->",
      "function": "validateClassNode",
      "file": "/home/andy/Personal/SymfonyCast/SymfonyAPI/api_platform/vendor/symfony/validator/Validator/RecursiveContextualValidator.php",
      "line": 313,
      "args": []
    },
    {
      "namespace": "Symfony\\Component\\Validator\\Validator",
      "short_class": "RecursiveContextualValidator",
      "class": "Symfony\\Component\\Validator\\Validator\\RecursiveContextualValidator",
      "type": "->",
      "function": "validateObject",
      "file": "/home/andy/Personal/SymfonyCast/SymfonyAPI/api_platform/vendor/symfony/validator/Validator/RecursiveContextualValidator.php",
      "line": 138,
      "args": []
    },
    {
      "namespace": "Symfony\\Component\\Validator\\Validator",
      "short_class": "RecursiveContextualValidator",
      "class": "Symfony\\Component\\Validator\\Validator\\RecursiveContextualValidator",
      "type": "->",
      "function": "validate",
      "file": "/home/andy/Personal/SymfonyCast/SymfonyAPI/api_platform/vendor/symfony/validator/Validator/RecursiveValidator.php",
      "line": 93,
      "args": []
    },
    {
      "namespace": "Symfony\\Component\\Validator\\Validator",
      "short_class": "RecursiveValidator",
      "class": "Symfony\\Component\\Validator\\Validator\\RecursiveValidator",
      "type": "->",
      "function": "validate",
      "file": "/home/andy/Personal/SymfonyCast/SymfonyAPI/api_platform/vendor/symfony/validator/Validator/TraceableValidator.php",
      "line": 66,
      "args": []
    },
    {
      "namespace": "Symfony\\Component\\Validator\\Validator",
      "short_class": "TraceableValidator",
      "class": "Symfony\\Component\\Validator\\Validator\\TraceableValidator",
      "type": "->",
      "function": "validate",
      "file": "/home/andy/Personal/SymfonyCast/SymfonyAPI/api_platform/vendor/api-platform/core/src/Bridge/Symfony/Validator/Validator.php",
      "line": 67,
      "args": []
    },
    {
      "namespace": "ApiPlatform\\Core\\Bridge\\Symfony\\Validator",
      "short_class": "Validator",
      "class": "ApiPlatform\\Core\\Bridge\\Symfony\\Validator\\Validator",
      "type": "->",
      "function": "validate",
      "file": "/home/andy/Personal/SymfonyCast/SymfonyAPI/api_platform/vendor/api-platform/core/src/Validator/EventListener/ValidateListener.php",
      "line": 68,
      "args": []
    },
    {
      "namespace": "ApiPlatform\\Core\\Validator\\EventListener",
      "short_class": "ValidateListener",
      "class": "ApiPlatform\\Core\\Validator\\EventListener\\ValidateListener",
      "type": "->",
      "function": "onKernelView",
      "file": "/home/andy/Personal/SymfonyCast/SymfonyAPI/api_platform/vendor/symfony/event-dispatcher/Debug/WrappedListener.php",
      "line": 117,
      "args": []
    },
    {
      "namespace": "Symfony\\Component\\EventDispatcher\\Debug",
      "short_class": "WrappedListener",
      "class": "Symfony\\Component\\EventDispatcher\\Debug\\WrappedListener",
      "type": "->",
      "function": "__invoke",
      "file": "/home/andy/Personal/SymfonyCast/SymfonyAPI/api_platform/vendor/symfony/event-dispatcher/EventDispatcher.php",
      "line": 230,
      "args": []
    },
    {
      "namespace": "Symfony\\Component\\EventDispatcher",
      "short_class": "EventDispatcher",
      "class": "Symfony\\Component\\EventDispatcher\\EventDispatcher",
      "type": "->",
      "function": "callListeners",
      "file": "/home/andy/Personal/SymfonyCast/SymfonyAPI/api_platform/vendor/symfony/event-dispatcher/EventDispatcher.php",
      "line": 59,
      "args": []
    },
    {
      "namespace": "Symfony\\Component\\EventDispatcher",
      "short_class": "EventDispatcher",
      "class": "Symfony\\Component\\EventDispatcher\\EventDispatcher",
      "type": "->",
      "function": "dispatch",
      "file": "/home/andy/Personal/SymfonyCast/SymfonyAPI/api_platform/vendor/symfony/event-dispatcher/Debug/TraceableEventDispatcher.php",
      "line": 151,
      "args": []
    },
    {
      "namespace": "Symfony\\Component\\EventDispatcher\\Debug",
      "short_class": "TraceableEventDispatcher",
      "class": "Symfony\\Component\\EventDispatcher\\Debug\\TraceableEventDispatcher",
      "type": "->",
      "function": "dispatch",
      "file": "/home/andy/Personal/SymfonyCast/SymfonyAPI/api_platform/vendor/symfony/http-kernel/HttpKernel.php",
      "line": 161,
      "args": []
    },
    {
      "namespace": "Symfony\\Component\\HttpKernel",
      "short_class": "HttpKernel",
      "class": "Symfony\\Component\\HttpKernel\\HttpKernel",
      "type": "->",
      "function": "handleRaw",
      "file": "/home/andy/Personal/SymfonyCast/SymfonyAPI/api_platform/vendor/symfony/http-kernel/HttpKernel.php",
      "line": 78,
      "args": []
    },
    {
      "namespace": "Symfony\\Component\\HttpKernel",
      "short_class": "HttpKernel",
      "class": "Symfony\\Component\\HttpKernel\\HttpKernel",
      "type": "->",
      "function": "handle",
      "file": "/home/andy/Personal/SymfonyCast/SymfonyAPI/api_platform/vendor/symfony/http-kernel/Kernel.php",
      "line": 199,
      "args": []
    },
    {
      "namespace": "Symfony\\Component\\HttpKernel",
      "short_class": "Kernel",
      "class": "Symfony\\Component\\HttpKernel\\Kernel",
      "type": "->",
      "function": "handle",
      "file": "/home/andy/Personal/SymfonyCast/SymfonyAPI/api_platform/vendor/symfony/runtime/Runner/Symfony/HttpKernelRunner.php",
      "line": 37,
      "args": []
    },
    {
      "namespace": "Symfony\\Component\\Runtime\\Runner\\Symfony",
      "short_class": "HttpKernelRunner",
      "class": "Symfony\\Component\\Runtime\\Runner\\Symfony\\HttpKernelRunner",
      "type": "->",
      "function": "run",
      "file": "/home/andy/Personal/SymfonyCast/SymfonyAPI/api_platform/vendor/autoload_runtime.php",
      "line": 35,
      "args": []
    },
    {
      "namespace": "",
      "short_class": "",
      "class": "",
      "type": "",
      "function": "require_once",
      "file": "/home/andy/Personal/SymfonyCast/SymfonyAPI/api_platform/public/index.php",
      "line": 5,
      "args": [
        [
          "string",
          "/home/andy/Personal/SymfonyCast/SymfonyAPI/api_platform/vendor/autoload_runtime.php"
        ]
      ]
    }
  ]

Hey Andrew M.!

Ok, I think I know what's going on... and you already figured it out :). Remove @Assert\Valid from above the username property. @Assert\Valid is only needed/used when a property is an object. It tells the validator system to recursively make sure that the object is ALSO valid. It's meaningless (and in fact gives you this error) if it's applied to a non-object property. For your username property, just put the normal NotBlank type of constraints that you need on it.

Let me know if that makes sense!

Cheers!!

That's great, I understand, thanks.

Hello Ryan!
I'm trying to make an embedded entity but with a non-doctrine object

How could I create a form with Embedding custom DTO Object property (This object is not a doctrine entity)?
For example:

Dto model:

class Point
{
    /**
     * @Groups({"point:write"})
     */
    public $latitude;

    /**
     * @Groups({"point:write"})
     */
    public $longitude;
}

Entity //@ORM\Entity

class City
{
      ....
      private $point;
}

Greetings!!!

Hey Juan,

To create a form - you need to use a custom form type for that "City::$point" field, that will contain 2 text fields: one for $latitude and one for $longitude. Then, Symfony Form component will know how to render that form, and how to read/write those values. But you will still need to think about how to store that non-doctrine object, probably you will need to use a serialization or json encode for that field - Doctrine has corresponding field types for this.

Cheers!

Hi Ryan,

I am having two entity with OneToOne relationship.

 
class User 
{
     /**
     * @ORM\OneToOne(targetEntity=ClientProfile::class, mappedBy="user", cascade={"persist", "remove"})
     * @Groups({"user:write"})
     */
    private $clientProfile;
}

class ClientProfile
{
   /**
     * @ORM\OneToOne(targetEntity=User::class, inversedBy="clientProfile", cascade={"persist", "remove"})     
     */
    private $user;
  
   /**
     * @ORM\Column(type="string")
     * @Groups({"user:write"})
     */
    private $test;
}

so can we add embedded field test inside "User" table ?

Hi Vishal T.!

Sorry for the slow reply!

so can we add embedded field test inside "User" table ?

I think you are asking whether or not you can make a POST /api/users request and send { "clientProfile": { "test": "foo" } } as the JSON so that you can change the embedded "test" property when updating/creating a user. Is this correct?

If so... then... yea! You have user:write groups on both User.clientProfile and ClientProfile.test, so you should be able to write that field in an embedded way. The interactive documentation should also reflect that fact. You would, of course, need methods like getClientProfile(), setClientProfile() and setTest(0 to make it work, but I think you are just not showing those to keep things short :).

Is this not working for you? If so, let me know what's going on - like any errors you are seeing.

Cheers!

Hi Ryan, thank you for this awesome serie of tutorials, really helpful.

Could you please give an example on how to accomplish this using DTO ?

I'm trying to adapt your code to create an Order entity that embed OrderItems, but I'm struggle.

Hey Auro

I believe this other tutorial may give you good ideas of how to do so
https://symfonycasts.com/sc...

Cheers!

Is it possible to update individual items in a collection during a PUT operation? Similar to how the CollectionType Field would updated enities if the id was present.

The body of my request (PUT /resource/uri/1) follows this structure:
`
{
"a_prop": "some value",
"collection": [

"@id": "/another_resources/uri/1",
"another_prop": "new value"

]
}
<br />The response will always return new uri for the item in the collection that is been updated (the previous one is getting deleted form db).<br />Resonse would look like this:<br />
{
...
"collection": [

"@id": "/another_resources/uri/2", // new uri 
"another_prop": "new value" // Updated value

]
}
`
I know the scenerario might be a little odd, but its all part of a old big form which the user may need to go back to and edit after it was already persisted to db. I'm considering splitting up the form to handle edits on a diferent view, but if possible i would like to avoid it. I wonder if its a configuration that i am missing (similar to the allow_add, allow_remove on the CollectionType), or is just not possible.

Hey Christopher hoyos!

Ha! Nice question. Tough question :). I think the answer is... yes! Um, maybe :P.

So, I tried this using this tutorial. Specifically, a made a PUT request to /api/users/8 and tried to update the "price" field on an existing cheeseListing with this body

{
  "cheeseListings": [
    {
      "@id": "/api/cheeses/1",
      "price": 500
    }
  ]
}

This DOES work. Assuming you've got all of your serialization groups set up (in this case, a user:write group is used when deserializing a User object and I've also added that same group to the CheeseListing.price property so that it can be updated), then it works just fine. This is a bit of a different result than you were getting... and I'm not sure why (well, your request and response body didn't look quite right to me - there should be an extra { } around each item inside the collection [] but I wasn't sure if that was a typo).

But, apart from needing the groups to be set up correctly, there is one catch: if the User has 2 cheese listings and you only want to edit one of them, you'll need to make sure you include ALL the cheese listings in the request, else the others will be removed. Something like this:

{
  "cheeseListings": [
    {
      "@id": "/api/cheeses/1",
      "price": 500
    },
    "/api/cheeses/4"
  ]
}

Personally, to manage complexity, I'd prefer to update these individual cheese listings by making a PUT request to /api/cheeses/1 instead of trying to do it all inside on request to update the user. But, I also understand that if you're refactoring a giant form... it may be more natural to combine it all at once. But, it's something to think about :). And now that your form is submitting via JavaScript, you could even start updating each CheeseListing (or whatever your other resource really is) on "blur" - i.e. when the user clicks off a field, send a PUT request right then to update just that one item.

Cheers!