Flag of Ukraine
SymfonyCasts stands united with the people of Ukraine

Synchronizing Owning & Inverse Sides

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

Ultimately, when we submit... we're still only updating the studiedGenuses property in User, which is the inverse side of this relationship:

... lines 1 - 16
class User implements UserInterface
{
... lines 19 - 77
/**
* @ORM\ManyToMany(targetEntity="Genus", mappedBy="genusScientists")
... line 80
*/
private $studiedGenuses;
... lines 83 - 236
}

So, nothing actually saves.

How can we set the owning side? Why not just do it inside the adder and remover methods? At the bottom of addStudiedGenus(), add $genus->addGenusScientist($this):

... lines 1 - 16
class User implements UserInterface
{
... lines 19 - 223
public function addStudiedGenus(Genus $genus)
{
if ($this->studiedGenuses->contains($genus)) {
return;
}
$this->studiedGenuses[] = $genus;
$genus->addGenusScientist($this);
}
... lines 233 - 238
}

Booya, we just set the owning side of the relationship!

In removeStudiedGenus(), do the same thing: $genus->removeGenusScientist($this):

... lines 1 - 16
class User implements UserInterface
{
... lines 19 - 233
public function removeStudiedGenus(Genus $genus)
{
$this->studiedGenuses->removeElement($genus);
$genus->removeGenusScientist($this);
}
}

So.... yea, that's all we need to do. Go back to the form, uncheck a genus, check a genus and hit update. It's alive!!!

We didn't need to add a lot of code to get this to work... but this situation has caused many developers to lose countless hours trying to get their relationship to save. To summarize: if you're modifying the inverse side of a relationship, set the by_reference form option to false, create an adder and remover function, and make sure you set the owning side of the relationship in each. That is it.

Synchronizing Both Sides

So, we're done! Well, technically we are done, but there is one last, tiny, teeny detail that I'd like to perfect. In Genus, when we call addGenusScientist(), it would be nice if we also updated this User to know that this Genus is now being studied by it. In other words, it would be nice if we called $user->addStudiedGenus($this):

... lines 1 - 14
class Genus
{
... lines 17 - 174
public function addGenusScientist(User $user)
{
if ($this->genusScientists->contains($user)) {
return;
}
$this->genusScientists[] = $user;
// not needed for persistence, just keeping both sides in sync
$user->addStudiedGenus($this);
}
... lines 185 - 199
}

I'm also going to add a note: this is not needed for persistence, but it might save you from an edge-case bug. Suppose we called $genus->addGenusScientist() to link a User to the Genus. Then later, during the same request - that's important - we have that same User object, and we call getStudiedGenuses(). We would want the Genus that was just linked to be in that collection. This does that! We're guaranteeing that both sides of the relationship stay synchronized.

Do the same thing down in the remover: $user->removeStudiedGenus($this):

... lines 1 - 14
class Genus
{
... lines 17 - 185
public function removeGenusScientist(User $user)
{
$this->genusScientists->removeElement($user);
// not needed for persistence, just keeping both sides in sync
$user->removeStudiedGenus($this);
}
... lines 192 - 199
}

Have Fun and Avoid Infinite Recursion!

That's great! Oh, except for one thing I just introduced: infinite recursion! When we call removeStudiedGenus(), that calls removeGenusScientist(), which calls removeStudiedGenus(), and so on... forever. And we are too busy to let our scripts run forever!

The fix is easy - I was being lazy. Add an if statement in the remove functions, like if !$this->studiedGenuses->contains($genus), then just return:

... lines 1 - 16
class User implements UserInterface
{
... lines 19 - 233
public function removeStudiedGenus(Genus $genus)
{
if (!$this->studiedGenuses->contains($genus)) {
return;
}
$this->studiedGenuses->removeElement($genus);
$genus->removeGenusScientist($this);
}
}

In other words, if the $genus is not in the studiedGenuses array, there's no reason to try to remove it.

Inside Genus, do the exact same thing: if !$this->genusScientists->contains($user), then return:

... lines 1 - 14
class Genus
{
... lines 17 - 185
public function removeGenusScientist(User $user)
{
if (!$this->genusScientists->contains($user)) {
return;
}
$this->genusScientists->removeElement($user);
// not needed for persistence, just keeping both sides in sync
$user->removeStudiedGenus($this);
}
... lines 196 - 203
}

Bye bye recursion.

Head back: uncheck a few genuses, check a few more and.... save! It works perfectly. We don't really notice this last perfection... but it may help us out in the future.

Leave a comment!

8
Login or Register to join the conversation
Default user avatar
Default user avatar Dominik | posted 5 years ago

One question: at this point the list of studiedGenuses in the UserEditForm ist unordered. I created a queryBuilder in the GenusRepository to solve this. Is there a faster way to solve this simple order thing? The Doctrine "OrderedBy" annotation does not seem to help in this case. It's already set.

Reply

Hey Dominik,

Actually, the faster way is the \@OrderBy() annotation, not \@OrderedBy(). Probably that was the case why you don't see any changes. But if you add @ORM\OrderBy({"name": "ASC"}) annotation to the field - it should do the trick. Don't forget to "use Doctrine\ORM\Mapping as ORM;" namespace.

Cheers!

1 Reply
Default user avatar

Thanks for the answer! Unfortunately my code is gone after refactoring it in the upcoming lessons :D (did no commit, DOH!) .. but i will keep that in mind!

Reply

Hey Dominik,

Haha, no problem! You can believe me it works, I tried by myself ;)

Cheers!

Reply
Paul Z. Avatar
Paul Z. Avatar Paul Z. | posted 5 years ago

When I go to the 'finish' folder of the course code I do not see any of this. Which chapter is the 'finish' folder from?

Reply

Hey Dave,

The "finish/" folder contains the code we have at the end of this course, i.e. it includes the code we have at the last chapter *and* all we did in previous chapters:
- "start/" directory holds the project at the start of the course
- "finish/" directory holds the project we've built at the end of the course, not a separate chapter

Cheers!

Reply

Sound the alarms!

We are glad that you liked our tutorials :)

Cheers!

Reply
Cat in space

"Houston: no signs of life"
Start the conversation!

This course is built on Symfony 3, but most of the concepts apply just fine to newer versions of Symfony.

What PHP libraries does this tutorial use?

// composer.json
{
    "require": {
        "php": "^7.1.3",
        "symfony/symfony": "3.4.*", // v3.4.49
        "doctrine/orm": "^2.5", // 2.7.5
        "doctrine/doctrine-bundle": "^1.6", // 1.12.13
        "doctrine/doctrine-cache-bundle": "^1.2", // 1.4.0
        "symfony/swiftmailer-bundle": "^2.3", // v2.6.7
        "symfony/monolog-bundle": "^2.8", // v2.12.1
        "symfony/polyfill-apcu": "^1.0", // v1.23.0
        "sensio/distribution-bundle": "^5.0", // v5.0.25
        "sensio/framework-extra-bundle": "^3.0.2", // v3.0.29
        "incenteev/composer-parameter-handler": "^2.0", // v2.1.4
        "composer/package-versions-deprecated": "^1.11", // 1.11.99.4
        "knplabs/knp-markdown-bundle": "^1.4", // 1.9.0
        "doctrine/doctrine-migrations-bundle": "^1.1", // v1.3.2
        "stof/doctrine-extensions-bundle": "^1.2" // v1.3.0
    },
    "require-dev": {
        "sensio/generator-bundle": "^3.0", // v3.1.7
        "symfony/phpunit-bridge": "^3.0", // v3.4.47
        "nelmio/alice": "^2.1", // v2.3.6
        "doctrine/doctrine-fixtures-bundle": "^2.3" // v2.4.1
    }
}
userVoice