This tutorial has a new version, check it out!
> Symfony 4 > Symfony Security: Beautiful Authentication, Powerful Authorization
Login to bookmark this video
Buy Access to Course
30.

Author ManyToOne Relation to User

Share this awesome video!

|

Keep on Learning!

Start your All-Access Pass

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

Login Subscribe

Check out the homepage: every Article has an author. But, open the Article entity. Oh: the author property is just a string!

249 lines | src/Entity/Article.php
// ... lines 1 - 15
class Article
{
// ... lines 18 - 47
/**
* @ORM\Column(type="string", length=255)
*/
private $author;
// ... lines 52 - 247
}

When we originally created this field, we hadn't learned how to handle database relationships yet.

But now that we are way more awesome than "past us", let's replace this author string property with a proper relation to the User entity. So every Article will be "authored" by a specific User.

Wait... why are we talking about database relationship in the security tutorial? Am I wandering off-topic again? Well, only a little. Setting up database relations is always good practice. But, I have a real, dubious, security-related goal: this setup will lead us to some really interesting access control problems - like denying access to edit an Article unless the logged in user is that Article's author.

Let's smash this relationship stuff so we can get to that goodness! First, remove the author property entirely. Find the getter and setter methods and remove those too. Now, find your terminal and run:

php bin/console make:migration

If our app were already deployed, we might need to be a little bit more careful so that we don't lose all this original author data. But, for us, no worries: that author data was garbage! Find the Migrations/ directory, open up the new migration file and yep! ALTER TABLE Article DROP author:

29 lines | src/Migrations/Version20180901184240.php
// ... lines 1 - 2
namespace DoctrineMigrations;
use Doctrine\DBAL\Schema\Schema;
use Doctrine\Migrations\AbstractMigration;
/**
* Auto-generated Migration: Please modify to your needs!
*/
final class Version20180901184240 extends AbstractMigration
{
public function up(Schema $schema) : void
{
// this up() migration is auto-generated, please modify it to your needs
$this->abortIf($this->connection->getDatabasePlatform()->getName() !== 'mysql', 'Migration can only be executed safely on \'mysql\'.');
$this->addSql('ALTER TABLE article DROP author');
}
public function down(Schema $schema) : void
{
// this down() migration is auto-generated, please modify it to your needs
$this->abortIf($this->connection->getDatabasePlatform()->getName() !== 'mysql', 'Migration can only be executed safely on \'mysql\'.');
$this->addSql('ALTER TABLE article ADD author VARCHAR(255) NOT NULL COLLATE utf8mb4_unicode_ci');
}
}

Adding the Relation

Now, lets re-add author as a relation:

php bin/console make:entity

Update the Article entity and add a new author property. This will be a "relation" to the User entity. For the type, it's another ManyToOne relation: each Article has 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! Hit enter to finish:

250 lines | src/Entity/Article.php
// ... lines 1 - 15
class Article
{
// ... lines 18 - 68
/**
* @ORM\ManyToOne(targetEntity="App\Entity\User", inversedBy="articles")
* @ORM\JoinColumn(nullable=false)
*/
private $author;
// ... lines 74 - 237
public function getAuthor(): ?User
{
return $this->author;
}
public function setAuthor(?User $author): self
{
$this->author = $author;
return $this;
}
}

Now run:

php bin/console make:migration

Like always, let's go check out the new migration:

33 lines | src/Migrations/Version20180901184346.php
// ... lines 1 - 2
namespace DoctrineMigrations;
use Doctrine\DBAL\Schema\Schema;
use Doctrine\Migrations\AbstractMigration;
/**
* Auto-generated Migration: Please modify to your needs!
*/
final class Version20180901184346 extends AbstractMigration
{
public function up(Schema $schema) : void
{
// this up() migration is auto-generated, please modify it to your needs
$this->abortIf($this->connection->getDatabasePlatform()->getName() !== 'mysql', 'Migration can only be executed safely on \'mysql\'.');
$this->addSql('ALTER TABLE article ADD author_id INT NOT NULL');
$this->addSql('ALTER TABLE article ADD CONSTRAINT FK_23A0E66F675F31B FOREIGN KEY (author_id) REFERENCES user (id)');
$this->addSql('CREATE INDEX IDX_23A0E66F675F31B ON article (author_id)');
}
public function down(Schema $schema) : void
{
// this down() migration is auto-generated, please modify it to your needs
$this->abortIf($this->connection->getDatabasePlatform()->getName() !== 'mysql', 'Migration can only be executed safely on \'mysql\'.');
$this->addSql('ALTER TABLE article DROP FOREIGN KEY FK_23A0E66F675F31B');
$this->addSql('DROP INDEX IDX_23A0E66F675F31B ON article');
$this->addSql('ALTER TABLE article DROP author_id');
}
}

Woh! I made a mistake! It is adding author_id but it is also dropping author. But that column should already be gone by now! My bad! After generating the first migration, I forgot to run it! This diff contains too many changes. Delete it. Then, execute the first migration:

php bin/console doctrine:migrations:migrate

Bye bye original author column. Now run:

php bin/console make:migration

Go check it out:

33 lines | src/Migrations/Version20180901184346.php
// ... lines 1 - 2
namespace DoctrineMigrations;
use Doctrine\DBAL\Schema\Schema;
use Doctrine\Migrations\AbstractMigration;
/**
* Auto-generated Migration: Please modify to your needs!
*/
final class Version20180901184346 extends AbstractMigration
{
public function up(Schema $schema) : void
{
// this up() migration is auto-generated, please modify it to your needs
$this->abortIf($this->connection->getDatabasePlatform()->getName() !== 'mysql', 'Migration can only be executed safely on \'mysql\'.');
$this->addSql('ALTER TABLE article ADD author_id INT NOT NULL');
$this->addSql('ALTER TABLE article ADD CONSTRAINT FK_23A0E66F675F31B FOREIGN KEY (author_id) REFERENCES user (id)');
$this->addSql('CREATE INDEX IDX_23A0E66F675F31B ON article (author_id)');
}
public function down(Schema $schema) : void
{
// this down() migration is auto-generated, please modify it to your needs
$this->abortIf($this->connection->getDatabasePlatform()->getName() !== 'mysql', 'Migration can only be executed safely on \'mysql\'.');
$this->addSql('ALTER TABLE article DROP FOREIGN KEY FK_23A0E66F675F31B');
$this->addSql('DROP INDEX IDX_23A0E66F675F31B ON article');
$this->addSql('ALTER TABLE article DROP author_id');
}
}

Much better: it adds the author_id column and foreign key constraint. Close that and, once again, run:

php bin/console doctrine:migrations:migrate

Failed Migration!

Woh! It explodes! Bad luck! This is one of those tricky migrations. We made the new column required... but that field will be empty for all the existing rows in the table. That's not a problem on its own... but it does cause a problem when the migration tries to add the foreign key! The fix depends on your situation. If our app were already deployed to production, we would need to follow a 3-step process. First, make the property nullable=true at first and generate that migration. Second, run a script or query that can somehow set the author_id for all the existing articles. And finally, change the property to nullable=false and generate one last migration.

But because our app has not been deployed yet... we can cheat. First, drop all of the tables in the database with:

php bin/console doctrine:schema:drop --full-database --force

Then, re-run all the migrations to make sure they're working:

php bin/console doctrine:migrations:migrate

Awesome! Because the article table is empty, no errors.

Adding Article Author Fixtures

Now that the database is ready, open ArticleFixtures. Ok: this simple setAuthor() call will not work anymore:

83 lines | src/DataFixtures/ArticleFixtures.php
// ... lines 1 - 10
class ArticleFixtures extends BaseFixture implements DependentFixtureInterface
{
// ... lines 13 - 24
private static $articleAuthors = [
'Mike Ferengi',
'Amy Oort',
];
// ... line 29
protected function loadData(ObjectManager $manager)
{
$this->createMany(10, 'main_articles', function($count) use ($manager) {
// ... lines 33 - 59
$article->setAuthor($this->faker->randomElement(self::$articleAuthors))
// ... lines 61 - 62
;
// ... lines 64 - 70
});
// ... lines 72 - 73
}
// ... lines 75 - 81
}

Nope, we need to relate this to one of the users from UserFixture. Remember we have two groups: these main_users and these admin_users:

60 lines | src/DataFixtures/UserFixture.php
// ... lines 1 - 9
class UserFixture extends BaseFixture
{
// ... lines 12 - 18
protected function loadData(ObjectManager $manager)
{
$this->createMany(10, 'main_users', function($i) use ($manager) {
// ... lines 22 - 40
});
$this->createMany(3, 'admin_users', function($i) {
// ... lines 44 - 54
});
// ... lines 56 - 57
}
}

Let's allow normal users to be the author of an Article. In other words, use $this->getRandomReference('main_users') to get a random User object from that group:

79 lines | src/DataFixtures/ArticleFixtures.php
// ... lines 1 - 10
class ArticleFixtures extends BaseFixture implements DependentFixtureInterface
{
// ... lines 13 - 24
protected function loadData(ObjectManager $manager)
{
$this->createMany(10, 'main_articles', function($count) use ($manager) {
// ... lines 28 - 54
$article->setAuthor($this->getRandomReference('main_users'))
// ... lines 56 - 57
;
// ... lines 59 - 65
});
// ... lines 67 - 68
}
// ... lines 70 - 77
}

At the top of the class, I can remove this old static property.

Try it! Move over and run:

php bin/console doctrine:fixtures:load

It works! But... only by chance. UserFixture was executed before ArticleFixtures... and that's important! It would not work the other way around. We just got lucky. To enforce this ordering, at the bottom of ArticleFixtures, in getDependencies(), add UserFixture::class:

79 lines | src/DataFixtures/ArticleFixtures.php
// ... lines 1 - 10
class ArticleFixtures extends BaseFixture implements DependentFixtureInterface
{
// ... lines 13 - 70
public function getDependencies()
{
return [
// ... line 74
UserFixture::class,
];
}
}

Now UserFixture will definitely run before ArticleFixtures.

If you try the fixtures again:

php bin/console doctrine:fixtures:load

Same result. But now, it's guaranteed!

Next - let's finish our refactoring and create a new "Article Edit" page!