Scroll down to the answer part if you just want the answer.
From what I can tell the Symfony documentation only shows how to access doctrine in your controllers( I am sure it is somewhere). But what if you need to access it in a service?
Services are any class within a folder inside the src folder, Repository folder for example. In Symfony 5+ every folder within src directory is considered a service folder, meaning the classes inside are services.
My current app has a very complex registration system and other forms. Not all of the fields are saved, and some go to different tables after processes are applied. For example the user alias is turned into a URL safe string to be used as their profile page.
So I started with all of the code I needed directly in the controller method, but that was a few hundred lines. Usually when I have a complex form that needs specific processing I create a processing class and save it in a folder called FormProcessors. Much of this same code can later be used with RabbitMq for example.
Inside the form processors I have public and private methods. I call the public methods from the controller methods to process the forms. You could split the code up within your controller class using private methods. I do that sometimes as I am building the form, I then move it to the form processors.
One added benefit of using the form processors is the logic can be copied over to new classes used with something like RabbitMQ when I move to an Event based system or microservices etc.
So I needed to figure out how to get to the dang doctrine orm inside my form processors, which is a service.
The answer
The answer is to type hint your Service class constructors with EntityManagerInterface like this(there are probably other ways too)
public function saveUserAlias( User $user, string $alias, DateTimeInterface $dateTimeObject){
$userAlias = new UserAlias();
$userAlias->setUser($user);
$userAlias->setAlias($alias);
$userAlias->setDatetimeAdded($dateTimeObject);
$this->entityManager->persist($userAlias);
$this->entityManager->flush();
}
Notice it is as simple as two calls to entityManager. You don’t have to even get the Repository. However you may get an error if you do not have your Repositories defined in your entities.
Scroll to the bottom to view a video of this Repository maker in action. I make about 100 Repositories in less than 2 minutes. You can go faster by just hitting enter really fast. LOL
NOTE – repository in the sense of this article means a Doctrine Repository Object. This object is used to interact with the database.
So you need to make a lot of basic Doctrine repositories for your Symfony 5 app? I needed to do the same thing. That is why I created a Doctrine Repository maker for Symfony 5+ or any version that contains the Maker Bundle and uses the src/Repository and src/Entity directory structure.
What happened is I was not very familiar with Doctrine and and the exact syntax it requires for everything in order to work properly. I don’t have the time to learn everything either. I often solve problems by finding the shortest solution time wise.
I know exactly how to design a database, I’ve studied that deeply. But I didn’t feel like wasting time to learn everything about Doctrine ORM just to be able to make queries and use migrations.
Plus I code in so many languages, I don’t have time to learn everything about every ORM… and that is why SQL was invented.
Not enough time to read it all.
So I have this seriously complex app I am building. It needs several hundred tables. I had well over 100 tables already created via MySQL Workbench. I love workbench because it is a nice UI that makes creating tables and making changes super fast and easy. Much faster than typing all of that mess into an Entity directly.
So what I did is I used Doctrine to reverse engineer my database and create the mapping to the Entity Annotations. That was a pain, but still faster than learning EVERYTHING about Doctrine and typing all that stuff in.
As a lazy programmer I like to go fast. LOL
The main problems with reverse engineering with Doctrine is it doesn’t create the repositories for the entities. And in order to use Doctrine with Symfony you need a Repository for each Entity, especially if you need custom queries/methods.
Another issue I had is if you do reverse engineer your database like this and you do create the repositories, you must then go into each Entity and add the Repository imports.
In order to create the Repositories for my new Entities, I created a maker. The maker gets a list of all of the Entities and existing Repositories. It then loops through each of the Entities that does not have a Repository and asks you if you would like to create one.
If you go with the naming path of the Repository maker it can overwrite files so be careful.
I also created an Entity clone maker, which I’ll talk about and share soon. Many of my Database tables were very similar, so I created an Entity cloner which can be used with Doctrine migrations and the Repository Maker to quickly finish building my app.
The Entity cloner also loops through entities and asks if you want to clone it. Very helpful.
Then Doctrine looks in the same directory as your Entity aka the entity folder and since it can’t find it you get this error. I found that adding a simple use statement to the top of the Entity file like so works well.
use App\Repository\UserRepository;
You can also just add the fully qualified Repository name like this.
It is a personal choice thing. I like the use statements because I am using PHP storm and it does use statements better than it does suggesting Repository names in the Entity annotations. Actually it doesn’t suggest the fully qualified path name so that is why I personally use “use” LOL
The only problem is this technique will only work with databases that are generically designed. Meaning you can’t use some of the DB vendor specific types etc.
This means if your database uses tinyint or enum for example you should undo that before trying to reverse engineer it with the link above. And god bless you if you have used tiny ints as foreign keys. You must delete all foreign keys first, then recreate them.
Seriously trying to figure out how to work around TinyInts and Enums is a real pain in the ass, I’d advise against it. This documentation page is written poorly it leaves lots of questions to be asked.
Doctrine is all like WTF do you need docs for?
Like WTF does this line even mean?
In this case however Schema-Tool update will have a hard time not to request changes for this column on each call.
Anyone want to have a stab at translating what WTF that means?
I need more details than that please. LOL
Use a backup
Step 1 use a backup
Don’t just backup your database. Start by dumping your current database structure, no data. Next import that into a new Schema. You can do that with one of the doctrine migration commands see this article.
Once you have the database structure imported. Open a terminal and do a quick doctrine migration diff as talked about here. Once you have the diff look over the migration to see what doctrine is wanting to change in your database schema. For me, It is easier to make those changes in something like MySQL Workbench with the added bonus that it can create an Entity Relationship diagram as part of my documentation.
Working with a backup of the data-structure lets you see what needs to be changed in your real database first. Follow the techniques in this article about reverse engineering the database.
Do the doctrine orm mapping import after you do the first diff. The purpose of the first diff is just to see the changes. You will see stuff like problems with TinyInts, Enums etc. Any vendor specific column type will generally be more trouble than it is worth.
Delete Migrations
Delete time
In the process of doing the diff and creating the mapping and doing the diff again and again, you end up with lots of migrations. Delete all of the migrations except for the very last diff migration.
You do the final diff after making final changes to the entity, mapping annotations. This way Doctrine can view your entities and compare them to your actual Schema. When you run this migration it will sync your database to the Entities.
No TinyInts
Sorry database designers you are not allowed to have these in your database design as they are mostly MySQL specific the Doctrine code does not allow them.
Doctrine is all like… NOPE
The Answer
Convert your tinyint columns to smallint. Doctrine understands those. Sure you are using like, a little more space each row now, but you really need Doctrine. LOL You can create a custom tinyint type, but wiring it in and using it is more of a pain than it is worth unless you really need it.
NO ENUMS
Remove Enums from your database design first
And the docs are wrong on this one and need updating. MySQL no longer requires an entire table rebuild costing hours.However Enums are not very useful because NULL and an empty string can be acceptable values under normal MySql configuration. Also with enums users can choose multiple values, so Doctrine uses php array type. You can use Enums, but it is more of a pain. See the doctrine docs here. You have to create a custom type and wire it in.
The Answer
Just use varchar or string as doctrine calls it. Make a check in your code (entity methods) to restrict values that are able to be accepted or make a table that holds the values. I personally use a table when there will be 10 or more values or I don’t know for certain how many there will be. If you use a table use a foreign link id to it in your main tables.
Forget your foreign key names
There is no solution for this. I have no idea why but Doctrine will absolutely rename,or suggest to rename every last foreign key.
Why can’t I have my foreign key names?
I think it tries to make sure each is unique or maybe it needs it in a specific format. I usually like to put the table name in it to be a hint in error output. But it also seems to rename keys it has previously renamed too.
The Answer
Like the leg humping dog in National Lampoon… “it’s best to let him finish”
I’ll post more as I find it.
Your Entities have no repositories
It is awesome that doctrine can reverse engineer a database and even create the repositories too. What I don’t understand is why it does not link the damn repository to the Entity. When you use the Entity maker it does this. When you reverse engineer with Doctrine it only creates the Entity mappings.
There is still one catch though. You will have much fun like I did, opening 100+ Entity files and adding the proper annotations for the matching Repository to it. I still have another maker to put on github that fixes some issues with entity/repository mapping.
This part is so tedious and fun
For example my app has a PageUrls Entity and it uses… PageUrlsRepository so to fix PageUrls so that I can use custom Repository methods I must now add this in the annotations.
So I must do this 100+ times now. I hope you have less tables in your database schema
Repetitive stuff is fun
I could add more code to the RepositoryMaker to update the Entities with the proper Repository tag. But then it is doing more than one thing. Maybe I should make a maker that updates the Entities Repository definition line to match. I’ve done this I just need to create the github repo add some stuff and publish it.
So you got this lovely error when trying to reverse engineer a database with doctrine. This error means that your database uses ENUM and is probably running on MySQL.
MySQL also contains SET which is about the same as ENUM except enum allows only 1 value from the list( or empty string or NULL) and set allows multiple values from the list. Doctrine doesn’t barf when it sees a SET but it sure does when it sees an ENUM.
Doctrine no ENUMs very well
Enums are ok when you know in advance that your app will only ever require a small number of options and you will allow empty strings or NULL. I usually go with a table when the number of options will be like 10+ , or I don’t know for sure how many items there could be.
However, working with Enums is a little difficult with Doctrine. Especially if you are trying to reverse engineer an existing database, you will get the following error :
Doctrine barfs when it encounters an ENUM
The easiest way to reverse engineer a database that exists already is to redesign it the Doctrine way. Remove all Enums and TinyInts. And if those tinyints were used in foreign key ids then, you must hunt down each one and remove it then you can add it again.
Then after you reverse engineer the database you can go into each and every single Entity that should be using an Enum and add the Enum to the Entity like so. Then you can rerun migrations:diff and update the database.
This article jokes about some of what I ran into and what I was thinking while I learned Doctrine. It does give some details and useful information. t_ is how you tell Doctrine to ignore a table in migrations. I was going to just tell Doctrine to ignore all my tables. LOL
To understand why DATA is the most important to me. Watch this video and read the subtitles. Warning you will laugh your ass off.
@2:14 you will understand why us older guys put the database and database design before any other part of the app. You can have 100000000000000000000 interfaces to a database, but if your data is fubar you are fucked. “We can reverse the code right? Sure thing, the database is still fucked though, of course you had bad code running on it” LMFAO Best part of the video.
The same thing happens when you let an ORM design a database and you don’t fully understand the ORM and how it sees data. Get the wrong Entity design and you get lots of redundant fields in your database, or NULLS or just a big mess. Your app might work… until it sees actual traffic. You don’t want to flop on your big day, trust me I’ve done it.
Plus if you design your system by entities then move to a different frame work or want to run two versions of your app using two different frameworks… WELL…
When you learn to do something with one tool and then that tool is taken away.
This does show an interesting way to learn doctrine.
The story
I’ve been designing databases for more than 10 years now. I studied the subject in depth and still own many books on it. I only started using frameworks in the last few years.
I think in terms of data and data manipulation needs while designing apps in order to design the best system. First I read the specifications closely and start designing the database based on those. I try to imagine what data needs to be collected in order to cover the specifications properly.
I decided to try to get doctrine to import the mapping.
The Symfony docs say it should work about 80% and you will need to fill in the rest. It doesn’t really say what the rest is, or give any tips. It kind of assumes you are a doctrine Wizard.
Yes I am now a doctrine wizard, because I don’t have to know it first LOL
The issue is, you must damn near be a Doctrine Wizard in order to understand exactly how the Entities should be modeled in order to match a database design. Otherwise you are like me and have to do this by trial and error wasting lots of time or spend months doing courses and tutorials. Nah, I’ll stick with designing my database the old way thanks.
I am a Wizard
If you have a sloppy Entity you have a sloppy database design. I had to learn how Doctrine would like an entity to be designed to match my database design.
So I became a doctrine wizard… sort of LMFAO
Well the first issue I ran into was using foreign keys as a composite primary key.
Doctrine was all like
doctrine no like primary foreign key
Ok so I changed my design so that every table had a unique ID instead of a unique foreign key primary key etc. I deleted most of my entities.
Then I run the command to rebuild the entities aka map them.
Now doctrine is not trying to change tinyint to smallint… but it wants to rename ALL of my foreign keys. WTF.
Lets rename the foreign keys for no F***ing reason
Ok that isn’t so bad, maybe it needs them named a specific way. I didn’t google that mess.
Lets get Cryptic with it.
I can live with cryptic foreign key names like…
FK_CA093F7E83172943
Not like I have to see them often. Other than when there is a DB error, now… instead of my beautiful Foreign key scheme which included the table name as a hint I get some cryptic bullshit in my messages and no way to track down WTF key it was.
It is the little things in programming.
Lets be Null together
But then I look closer and now the diff command wants to change all of my foreign keys to default null.
Freaking seriously
The purpose of a foreign key is to make the database make sure a value exists in one table before inserting a value that links to it in another table. This is known as referential integrity.
This is where I draw the line with Doctrine
Sorry doctrine. No I will not ruin my database design just to use you.
Allowing nulls on a foreign key is STUPID. This means that now your application code must make sure a value is not null before inserting it and it must exist in the other table first… GO HOME YOU ARE DRUNK, TAKE SISTER NULL BACK TO JAVALAND FFS.
Which means you can’t use some of symfony’s validation techniques because they rely on the same Entity class annotations. Sure you can add to the form validation, but you still need to make sure a value exists in the linked table before you can insert it or else you insert a null value, which destroys referential integrity.
Null values on foreign keys just make no sense to me.
That makes no damn logical sense!
So in order to use Doctrine it looks to me like I must ruin my beautiful table design. I only wanted to use it for the migrations and some ease of use deals. But I do not want to destroy my database to do so.
For example if I have a hashtagged_images table and that table contains a hashtag_id and an image_id . A table like the following
hashtagged_images
id
hashtag_id
image_id
Why would I ever want either of those to be null? That is like dividing by zero. You never ever, want either of those null, that will make your database a flaming hot mess.
Yay lets have nulls in the database
Now your code must check whether anything contains a null before your app can use it. It must also make sure that before you insert a hashtag for an image that you must first hit the hashtags table to make sure a hashtag with a specific id exists. Then you must hit the images table too, to make sure an image with such an ID exists. Then you can finally insert your images hashtag.
That is a ton of work when a simple “not null foreign key” constraint would do all of that for you. It would also shift the query work from the app to the database like it should be.
A new team member may not know your system and forget to check for null for example. Here is more info about nulls in the database.
Null is only useful when you have a table with columns that don’t need a value when the record is initially inserted. Something like a collection ID for an image a user uploads. It very well may not belong to a collection, therefore you would need to allow for a NULL field value or have a default value.
These days I try to just create default values for everything. I try to have as few Nulls in the database as possible. The longer you program, the more you hate NULL.
Nope, Not gonna do it…
So that is how I came to prefixing all tables with t_ so that Doctrine would leave them alone.
I kept trying and trying to make changes
But I have this disorder that makes me INSANELY persistent.
I refused to leave this alone. So I kept making changes and running this command
Then running a migration diff and viewing the changes that doctrine wanted to make in the migration up.
Then I got this idea.
Then I got an idea!!!
What if I try adding nullable=false to the join column definitions? I didn’t bother googling it or trying to find it in the damn docs. I just did it.
Let me just try this.
So after I added that and reran the diff, not the entity mapping, and BOOM Doctrine was no longer suggesting in the migration up that it should change the foreign key to default to null.
Boom I won.
So when you want your foreign keys which are an ID in another linked table to not be null like they should be. You should have a definition like this in your Entity
This tiny little line nullable=false changes everything. It tells Doctrine you do not want that field to be nullable.
I don’t know why the Doctrine mapping code can’t get this right. This information is provided to it by the DB query. Maybe I could help find this code and update it so that it includes this tiny line if the DB query returns it.
The story must go on…
but there is still more stuff to do
You also need to fix EVERY LAST ENTITY NOW. Yes for each and every entity you must now open the file and list the damn repository for it. For some reason the Doctrine code can’t do this either, even though the Repository is just the Entity name with Repository added to it.
now I do more work.
So open up every last single Entity and create a line like this above the class definition in a comment (I also created another maker to fix this, I still need to create a repo etc. for it)
Here is the issue. If you follow along the docs for Doctrine when working on a Symfony framework, you will get issues every once and a while.
./vendor/bin/doctrine-migrations status --show-versions
Something missing or not configured correctly etc. That line is copied and pasted directly from the Doctrine documentation . To use Doctrine this way with Symfony, you must do some further configurations to Doctrine.
If you are using Symfony there is an easier way, unless you must absolutely use Doctrine like that. As programmers we love the easier way right…
Symfony makes it easier to work with Doctrine
What I like to do is use Doctrine with the plain php bin/console. But first I had to figure out how to do that.
Step 1, show console commands
To show the console commands available type the following while in the main directory for you app( the one with public, src, var, etc.)
php bin/console list
This will output a long list of all of the commands you can use in the console with php bin/console xxx-name-of-command.
Here is what mine output.
As you can see there are a lot of commands and a lot of them for doctrine.
doctrine
doctrine:cache:clear-collection-region Clear a second-level cache collection region
doctrine:cache:clear-entity-region Clear a second-level cache entity region
doctrine:cache:clear-metadata Clears all metadata cache for an entity manager
doctrine:cache:clear-query Clears all query cache for an entity manager
doctrine:cache:clear-query-region Clear a second-level cache query region
doctrine:cache:clear-result Clears result cache for an entity manager
doctrine:database:create Creates the configured database
doctrine:database:drop Drops the configured database
doctrine:database:import Import SQL file(s) directly to Database.
doctrine:ensure-production-settings Verify that Doctrine is properly configured for a production environment
doctrine:fixtures:load Load data fixtures to your database
doctrine:mapping:convert [orm:convert:mapping] Convert mapping information between supported formats
doctrine:mapping:import Imports mapping information from an existing database
doctrine:mapping:info
doctrine:migrations:current [current] Outputs the current version
doctrine:migrations:diff [diff] Generate a migration by comparing your current database to your mapping information.
doctrine:migrations:dump-schema [dump-schema] Dump the schema for your database to a migration.
doctrine:migrations:execute [execute] Execute one or more migration versions up or down manually.
doctrine:migrations:generate [generate] Generate a blank migration class.
doctrine:migrations:latest [latest] Outputs the latest version
doctrine:migrations:list [list-migrations] Display a list of all available migrations and their status.
doctrine:migrations:migrate [migrate] Execute a migration to a specified version or the latest available version.
doctrine:migrations:rollup [rollup] Rollup migrations by deleting all tracked versions and insert the one version that exists.
doctrine:migrations:status [status] View the status of a set of migrations.
doctrine:migrations:sync-metadata-storage [sync-metadata-storage] Ensures that the metadata storage is at the latest version.
doctrine:migrations:up-to-date [up-to-date] Tells you if your schema is up-to-date.
doctrine:migrations:version [version] Manually add and delete migration versions from the version table.
doctrine:query:dql Executes arbitrary DQL directly from the command line
doctrine:query:sql Executes arbitrary SQL directly from the command line.
doctrine:schema:create Executes (or dumps) the SQL needed to generate the database schema
doctrine:schema:drop Executes (or dumps) the SQL needed to drop the current database schema
doctrine:schema:update Executes (or dumps) the SQL needed to update the database schema to match the current mapping metadata
doctrine:schema:validate Validate the mapping files
I believe the replacement for the failed show-versions command above is this
php bin/console doctrine:migrations:list
Which will output information in the following format.
Output of the command php bin/console doctrine:migrations:list
If I had migrations they would be listed and those values shown would be in rows.
Ok why can't you see my environmental variables now?
So while following this guide in the documentation to try to reverse engineer my database with Doctrine, I got the following 100% absolutely nonsensical error
Importing mapping information from "default" entity manager
writing src/Entity/AffiliateArticleViews.php
writing src/Entity/AffiliateJoinCounts.php
writing src/Entity/AffiliateRegistration.php
writing src/Entity/BlogMedia.php
writing src/Entity/CommentReplyConclusionOptions.php
writing src/Entity/CommentReplyReportReasons.php
writing src/Entity/DoctrineMigrationVersions.php
writing src/Entity/FavoredImages.phP
In DebugClassLoader.php line 346:
Warning: include(/var/www/sogi/sogizmo/vendor/composer/../../src/Entity/FavoredImages.php): failed to
open stream: No such file or directory
To someone who doesn’t work on the Symfony core that might as well say “boasdfkajsdfiioaysdfiuasdfiouasdfiouasdiofu”
So I had to research this issue.
Doing Research!!!
Ok so I found this link with a little more info and I ran the following line of code.
Which barfed out these lines of more mysteries to be solved.
You are missing a "cli-config.php" or "config/cli-config.php" file in your project, which is required to get the Doctrine Console working. You can use the following sample as a template:
<?php use Doctrine\ORM\Tools\Console\ConsoleRunner; // replace with file to your own project bootstrap require_once 'bootstrap.php'; // replace with mechanism to retrieve EntityManager in your app $entityManager = GetEntityManager(); return ConsoleRunner::createHelperSet($entityManager); </code
Leaving me wondering WTF is this even talking about like…
Who comes up with this?
Google and dig as I may I only found one Stack answer that explained how to created the mess of files required. Sure would be nice if that was in the Doctrine docs…
But I kept digging, trying, failing… and it turns out that the first error I got means…. wait for it…. MY USER DOCTRINE IS RUNNING AS CAN’T WRITE TO THE DIRECTORY. Now wouldn’t it make much more sense to give that as an error message?
MAKES ABSOLUTE PERFECT SENSE
So I changed the Entity directory permissions to 775 since my server www-data was already a member of a group which was the group owner of that directory. And the first command finally worked like it had before. Some how somewhere along the way I set permissions on the Entity and all folders to 755.
The error messages were no help. I just randomly decided to try creating another test folder with 775 and ran the first command again. I accidentally guessed what the problem was from a nonsensical error message. Desperation wins in the problem solving game. LOL
That wasn’t the end though. When I tried to run the second command I got another nonsensical error about my Entity classes already exist. I was like I know the first command created them WTF. Kept googling and searching and scratching my head. Then I remembered I created the test folder so I deleted it and BOOM BANG POW. Everything was working fine.
Basically if you want to remove a column from a table when using Doctrine and Symfony Entities all you do is remove the variable and the matching getter/setter methods from the Entity, then run a diff.
php bin/console doctrine:migrations:diff
instead of making a migration, this command makes the migration file for you. Then you can run this command to change the table.
Make sure you don’t have other migrations ready before running this command or all of them get executed. You can follow the advice in the console after issuing the above command and use “execute” instead with the name of the exact migration you want to use.
php bin/console doctrine:migrations:migrate
What is happening is Doctrine ORM is used to map the Database tables to an Entity. Every Doctrine/Symfony Entity matches 1 table in a database.
Lets view an example. This Entity should be familiar to anyone who created an app using the Symfony maker system. User.php should be located in app\src\Entity\User.php and it looks basically like this.
<?php namespace App\Entity; use App\Repository\UserRepository; use Doctrine\ORM\Mapping as ORM; use Symfony\Component\Security\Core\User\UserInterface; /** * User * * @ORM\Table(name="user", uniqueConstraints={@ORM\UniqueConstraint(name="email_UNIQUE", columns={"email"})}, indexes={@ORM\Index(name="email", columns={"email"})}) * @ORM\Entity(repositoryClass=UserRepository::class) */ class User implements UserInterface { /** * @var int * * @ORM\Column(name="id", type="bigint", nullable=false, options={"unsigned"=true}) * @ORM\Id * @ORM\GeneratedValue(strategy="IDENTITY") */ private int $id; /** * @var string * * @ORM\Column(name="email", type="string", length=255, nullable=false) */ private string $email; /** * @var string * * @ORM\Column(name="password", type="string", length=255, nullable=false) */ private string $password; /** * @var array|null * * @ORM\Column(name="roles", type="json", nullable=true) */ private ?array $roles; /** * @var string|null * * @ORM\Column(name="web_token", type="string", length=255, nullable=true) */ private ?string $webToken; /** * @var string|null * * @ORM\Column(name="api_token", type="string", length=255, nullable=true) */ private ?string $apiToken; public function getId(): ?string { return $this->id;
}
public function getEmail(): ?string
{
return $this->email;
}
public function setEmail(string $email): self
{
$this->email = $email;
return $this;
}
public function getPassword(): ?string
{
return $this->password;
}
public function setPassword(string $password): self
{
$this->password = $password;
return $this;
}
public function getRoles(): ?array
{
return $this->roles;
}
public function setRoles(?array $roles): self
{
$this->roles = $roles;
return $this;
}
public function getWebToken(): ?string
{
return $this->webToken;
}
public function setWebToken(?string $webToken): self
{
$this->webToken = $webToken;
return $this;
}
public function getApiToken(): ?string
{
return $this->apiToken;
}
public function setApiToken(?string $apiToken): self
{
$this->apiToken = $apiToken;
return $this;
}
public function getSalt()
{
// TODO: Implement getSalt() method.
}
public function getUsername(): ?string
{
// TODO: Implement getUsername() method.
return $this->getEmail();
}
public function eraseCredentials()
{
// TODO: Implement eraseCredentials() method.
}
}
As you can see I have a web token and api token in this class. If I wanted to remove the web token from my database I simply remove the relate variable and getter/setters like so.
<?php namespace App\Entity; use App\Repository\UserRepository; use Doctrine\ORM\Mapping as ORM; use Symfony\Component\Security\Core\User\UserInterface; /** * User * * @ORM\Table(name="user", uniqueConstraints={@ORM\UniqueConstraint(name="email_UNIQUE", columns={"email"})}, indexes={@ORM\Index(name="email", columns={"email"})}) * @ORM\Entity(repositoryClass=UserRepository::class) */ class User implements UserInterface { /** * @var int * * @ORM\Column(name="id", type="bigint", nullable=false, options={"unsigned"=true}) * @ORM\Id * @ORM\GeneratedValue(strategy="IDENTITY") */ private int $id; /** * @var string * * @ORM\Column(name="email", type="string", length=255, nullable=false) */ private string $email; /** * @var string * * @ORM\Column(name="password", type="string", length=255, nullable=false) */ private string $password; /** * @var array|null * * @ORM\Column(name="roles", type="json", nullable=true) */ private ?array $roles; /** * @var string|null * * @ORM\Column(name="api_token", type="string", length=255, nullable=true) */ private ?string $apiToken; public function getId(): ?string { return $this->id;
}
public function getEmail(): ?string
{
return $this->email;
}
public function setEmail(string $email): self
{
$this->email = $email;
return $this;
}
public function getPassword(): ?string
{
return $this->password;
}
public function setPassword(string $password): self
{
$this->password = $password;
return $this;
}
public function getRoles(): ?array
{
return $this->roles;
}
public function setRoles(?array $roles): self
{
$this->roles = $roles;
return $this;
}
public function getApiToken(): ?string
{
return $this->apiToken;
}
public function setApiToken(?string $apiToken): self
{
$this->apiToken = $apiToken;
return $this;
}
public function getSalt()
{
// TODO: Implement getSalt() method.
}
public function getUsername(): ?string
{
// TODO: Implement getUsername() method.
return $this->getEmail();
}
public function eraseCredentials()
{
// TODO: Implement eraseCredentials() method.
}
}
Now when you run the migrations:diff command a new migration file will be created. Inside that file will be the queries to make the changes in the “up” method of that migrations file. In the “down” method you will find the code to restore the database and add the column back, which will also update the Entity class.
After you run the diff you run a migration. Running the migration changes your database to match your changes in your Entity class.
Tips
#1 One entity at a time
The first tip I’d give is to work on only one entity at a time. That means change only one entity file, then run the diff, then migrate. You will often run into issues and it is easier to fix those issues one at a time than many at once.
#2 Check for indexes
When you remove a column, look to the top of the file to make sure there are not any indexes on those columns or else you will get errors.
check for indexes too
#3 Give divorces
Make sure you note any column that is used in any entity relationship, you will need to give them proper divorces. LOL Basically if you have two tables that are linked by an id, don’t delete an entity if that entity is referred to in another entity. This will get barf all over you.
Symfony/Doctrine will barf on you.
First find all the entities that your entity is referred to in and delete each one. then you can delete the entity itself. The easy way to do this is to use your IDE to “Find usages” of the class. Find each entity file that uses it and delete the reference. Also delete the import statement.
