When we used make:entity to add a relation, it asked us about orphanRemoval. Time to find out what that is & when to use it. In the fixtures, start with $starshipPart = StarshipPartFactory::createOne(). To make it stand out, I'll make this a crucial…

…it's getting a bit long. Then, add one magical option: orphanRemoval = true: That's the key. It says: If one of these GenusScientist objects suddenly has their genus set to null, just delete it entirely. Give it a try! Refresh the form to…

…it's all about the objects! Handling relationships in fixtures with Foundry The OneToMany "inverse" side of a relation Filtering a collection of related objects with Criteria orphanRemoval (not as heartless as it sounds!) Querying with Joins Solving the N+1 problem ManyToMany Relations ManyToMany…

…collection) side of a relation (bonus) Using DoctrineExtension for clean URL slugs Keeping the owning & inverse sides in-sync Using orphanRemoval to delete items in a collection Using cascade to save items in a collection Counting collections in the EXTRA_LAZY way Rendering relationship data…

…must be related to an Article. Say yes to map the other side of the relationship - it's convenient to be able to say $article->getArticleReferences(). And no to orphan removal - we won't be using that feature. Nice! Ok, this needs a few more…

…later, because you want to be able to fetch a User in your API and instantly see what treasures it has. Anyways, the property - dragonTreasures inside of User is fine.... and finally, for orphanRemoval, say no. We'll also talk about that later. And... done…

…the dragonTreasures property. After cascade, add one more option here: orphanRemoval: true. This tells Doctrine that if any of these dragonTreasures become "orphaned" - meaning they no longer have any owner - they should be deleted. Let's try it. When we hit "Execute" again... got it…

…way to force this and say: If an Answer ever becomes orphaned, please delete it. It's called "orphan removal". Inside of Question, scroll up to find the $answers property... here it is. On the end, add orphanRemoval set to true: Now refresh and... yes…

…it doesn't matter for authentication, let's map both sides of the relationship. That will allow us to easily fetch all of the API tokens for a specific user. For orphanRemoval, this is also not important, but choose yes. If we create a page…

…one User and each User can have many articles. The author property will be required, so make it not nullable. We'll say "yes" to mapping the other side of the relationship and I'll say "no" to orphanRemoval, though, that's not important. Cool…

…a property in the JSON, you'll also want this. More on that soon. Anyways, say yes, call the property cheeseListings and say no to orphanRemoval. If you're not familiar with that option... then you don't need it. And... bonus! A bit later…

…except that this will generate a little bit more code. What should that new property in the Question entity be called? Use the default answers. Finally it asks a question about orphanRemoval. This is a bit more advanced... and you probably don't need it…

…about the owning and the inverse sides of the relationship, and things called orphanRemoval and cascading. There is some significant Doctrine magic going on behind the scenes to get it working. So in a few minutes, we're going to look at a more custom…

…simple way to get all the parts for a ship. There's also no downside. So this is a "yes" for me dawg. Call the property parts: short and sweet. For orphan removal, say "no". We'll dive into that later. Hit enter to finish…

…might be handy, so let's say yes. And call that property questions. Finally, I'm going to say no to orphan removal. And... done! If you went through our Doctrine relationships tutorial, then you know that there's nothing special here. This added a…

…$question->getQuestionTags()? That probably will be handy, so say yes. Call that property $questionTags. Finally, say "no" to orphan removal. Cool! The other property - the tag property - will be exactly the same: a ManyToOne, related to Tag, say "no" for nullable and, in this case…

…astound your friends with your newfound knowledge, then promptly forget about it: it's not critical in practice. Clean up our temporary code here and freshen things up by reloading the fixtures: Alright, next up: orphanRemoval. It's not nearly as mean as it sounds.

…Behind the scenes, its owner was set to null. Then, thanks to orphanRemoval, any time the owner of one of these dragonTreasures is set to null, it gets deleted. That's something we talked about in a previous tutorial. Before we move on, we need…

…you understand the mapping and the inverse side reality, you write your code to update the mapping side from the inverse side, and understand a few things like orphanRemoval and cascade, everything falls into place. Now that you guys know what to do, go forth…

…property in Article, use the default: comments. Finally, it asks you about something called orphanRemoval. Say no here. This topic is a bit more advanced, and you probably don't need orphanRemoval unless you're doing something complex with Symfony form collections. Oh, and we…