Removing Items from a Collection

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.

Start your All-Access Pass
Buy just this tutorial for $12.00

With a Subscription, click any sentence in the script to jump to that part of the video!

Login Subscribe

Close up the POST operation. I want to make a GET request to the collection of users. Let's see here - the user with id 4 has one CheeseListing attached to it - id 2. Ok, close up that operation and open up the operation for PUT: I want to edit that User. Enter 4 for the id.

First, I'm going to do something that we've already seen: let's just update the cheeseListings field: set it to an array with one IRI inside: /api/cheeses/2. If we did nothing else, this would set this property to... exactly what it already equals: user id 4 already has this one CheeseListing.

But now, add another IRI: /api/cheeses/3. That already exists, but is owned by another user. When I hit Execute.... pfff - I get a syntax error, because I left an extra comma on my JSON. Boo Ryan. Let's... try that again. This time... bah! A 400 status code:

This value should not be blank

My experiments with validation just came back to bite me! We set the title for CheeseListing 3 to an empty string in the database... it's basically a "bad" record that snuck in when we were playing with embedded validation. We could fix that title.. or... just change this to /api/cheeses/1. Execute!

The Serializer only Calls Adders for New Items

This time, it works! But, no surprise - we've basically done this! Internally, the serializer sees the existing CheeseListing IRI - /api/cheeses/2, realizes that this is already set on our User, and... does nothing. I mean, maybe it goes and gets a coffee or takes a walk. But, it most definitely does not call $user->addCheeseListing()... or really do anything. But when it sees the new IRI - /api/cheeses/1, it figures out that this CheeseListing does not exist on the User yet, and so, it does call $user->addCheeseListing(). That's why adder and remover methods are so handy: the serializer is smart enough to only call them when an object is truly being added or removed.

Removing Items from a Collection

Now, let's do the opposite: pretend that we want to remove a CheeseListing from this User - remove /api/cheeses/2. What do you think will happen? Execute and... woh! An integrity constraint error!

An exception occurred when executing UPDATE cheese_listing SET owner_id=NULL - column owner_id cannot be null.

This is cool! The serializer noticed that we removed the CheeseListing with id = 2. And so, it correctly called $user->removeCheeseListing() and passed CheeseListing id 2. Then, our generated code set the owner on that CheeseListing to null.

Depending on the situation and the nature of the relationship and entities, this might be exactly what you want! Or, if this were a ManyToMany relationship, the result of that generated code would basically be to "unlink" the two objects.


But in our case, we don't ever want a CheeseListing to be an "orphan" in the database. In fact... that's exactly why we made owner nullable=false and why we're seeing this error! Nope, if a CheeseListing is removed from a User... I guess we really need to just delete that CheeseListing entirely!

And... yea, doing that is easy! All the way back up above the $cheeseListings property, add orphanRemoval=true.

... lines 1 - 22
class User implements UserInterface
... lines 25 - 58
* @ORM\OneToMany(targetEntity="App\Entity\CheeseListing", mappedBy="owner", cascade={"persist"}, orphanRemoval=true)
... lines 61 - 62
private $cheeseListings;
... lines 65 - 185

This means, if any of the CheeseListings in this array suddenly... are not in this array, Doctrine will delete them. Just, realize that if you try to reassign a CheeseListing to another User, it will still delete that CheeseListing. So, just make sure you only use this when that's not a use-case. We've been changing the owner of cheese listings a bunch... but only as an example: it doesn't really make sense, so this is perfect.

Execute one more time. It works... and only /api/cheeses/1 is there. And if we go all the way back up to fetch the collection of cheese listings... yea, CheeseListing id 2 is gone.

Next, when you combine relations and filtering... well... you get some pretty serious power.

Leave a comment!

  • 2019-08-05 weaverryan

    Hey Eric !

    Cool question :). We've just started releasing our security tutorial - - and this is *exactly* the kind of stuff I hope to clear up there. But, let me answer now and we can make sure that I'm answering everything clearly :).

    There are two parts to this that I can see:

    > 1) How do I restrict access (e.g. GET) to a specific CheeseListing so that only a User that belongs to a UserGroup that owns a CheeseListing can access it?

    First, don't use sub resources :). I just wanted to mention that first - because it can complicate things a bit (as you might successfully secure the GET operation for cheese listings, but forget that you've exposed cheeseListings as a sub-resource of some other entity... or something like that ;).

    To solve this problem, you'll use two things: (A) access_control ( with voters. So, I might use something like access_control"="is_granted('READ', previous_object)". Then you would have a custom voter that is able to decide whether or not the current user has "READ" access (I just invented that string) to this CheeseListing (that's what "previous_object" represents, and is passed to your voter - it is the CheeseListing object *before* it was modified by the request). And (B) you will probably need a custom Doctrine extension ( so that you can also *filter* the collection resource by this same logic (so that when you make a GET collection to /api/cheeses, you only see what you should see).

    > 2) How can I change ownership of a CheeseListing?

    I think this might also be part of your question. In your model, changing ownership would mean that you're changing, for example, the "group" property on a CheeseListing. Other than security, that's trivial: you're just updating a property on CheeseListing. But to prevent a "bad" user from doing this (e.g. to prevent someone from changing the CheeseListing from some OTHER group to their OWN group) you would leverage access_control once again - the previous_object variable I mention above will contain the property *before* it was changed. So, naturally, your voter logic will see if the user making this request belongs to the group of this CheeseListing or not.

    A similar question to 2 is: what if they "pass" my access_control successfully (they DO have access) but then I need to make sure that the new is a value that they are allowed to use? For example, suppose i CAN access this CheeseListing, but I'm trying to change its group to some group that I'm not part of. That should not be allowed. The answer to this is indeed a custom validation constraint.

    Let me know if this helps! There are about 4 different subtle different "ways" to protect a resource (protect entire resource/operation, change fields based on the user, prevent bad data from being set, etc) and each has a specific solution. This will all be in the security tutorial :).


  • 2019-08-05 Victor Bocharsky

    Hey Eric,

    Good question! I think you're on the right direction here, probably using custom validation constraints in this case would be the most flexible and powerful solution. Nothing much except this can advise here :/


  • 2019-08-02 Eric

    Was thinking about this last night and I guess you could just use custom validation constraints to handle this - which I believe would be the most appropriate way to handle this.

  • 2019-08-02 Eric

    Having a hard time wrapping my head around how one would leverage reassigning ownership of an entity, like being done here, in an application that has more strict ownership rules.

    For example:
    If we had 3 entities (User, UserGroup and CheeseListing) where users should not be able to interact with cheese listings that are outside of their user's user group - how would one apply those rules? As it stands now, a user could be assigned any cheese listing - instead of only being able to be assigned a subset of cheese listings in which it should have access. I've been trying to search the docs to figure this out but not coming up with any right way to implement this. I see mention of using access control to limit access to sub-resources ( but if that is limited to roles and such, and a user could have the same role across user groups, I'm not sure how to approach the problem.

    Any suggestions are appreciated. Figure this is probably a pretty common situation so perhaps I am just overlooking something. My mind goes to multi-tenant applications where this would be needed on most any related resource.

  • 2019-07-01 Ramazan

    Hey Diego Aguiar ,

    Thank you for the suggestion. Finally I did something by myself instead of using another vendor.
    My solution is this one, and it works:

    If anyone try it, I will appreciate any feedback.

  • 2019-06-28 Diego Aguiar

    Hey Ramazan

    I'm not sure but I would say yes, you have to remove the "orphan" config and do the update yourself. But it seems to me that what you want is something similar as the "SoftDeleteable" extension. Give it a check and decide if it fits your needs or not ( )


  • 2019-06-28 Ramazan

    In a real situation nobody will remove the orphan, instead I want to set another field like isRemoved=1. Is there a way to do that or we have to update this field separately?